[TriLUG] Adding to the list of topics: IPv6

[Ryan Leathers]

NAT is a neat trick and has filled a certain need, BUT...

Some of you humming the "Give NAT a Chance" melody might do well to
consider the EVILS of NAT.  

First - the pet peeve point
If I see one more reader of this list tout the fools claim that NAT
affords a valuable level of security I'll pull my few remaining hairs
out.  Methods for NAT subversion were well understood even before NAT
was popularized, yet even technical professionals beat their drums of
false security to this day.  

Second - the timely example point
Lots of talk about VoIP lately - - - NAT is public enemy number one for
many a VoIP connection.  Better firewalls / gateways handle the needed
translations when NAT is in play, but cheapo consumer grade NAT boxes
can kill VoIP faster than a Baby Bell can think up a new fee.

Summary - NAT is the spawn of some unseen dark power conspiring with
evil consumer-grade hardware vendors to shackle you with exploitable
false security and deny you the goodness of VoIP.  Was that over the
top?  

IPV6... a better network... a better life.  

On Thu, 2004-01-22 at 09:57, Jon Carnes wrote:
> On Thu, 2004-01-22 at 01:22, William Sutton wrote:
> > I'm still not sure I want my appliances logging in and telling the 
> > manufacturer who-knows-what, but under the supposition that they do, I'm 
> > curious:  Why not have your appliances NAT'd behind the router for your 
> > house?
> 
> Well, how many houses run a firewall or have a NAT?  How many houses
> have a refrigerator?
> 
> The NAT argument is fine - you can get these things to work behind a
> NAT, but...
> 
> 1) That removes the functionality from the masses. Manufacturers would
> then be setting up these systems to work for only an elite few.
> That destroys your economy of scale and makes it too expensive to setup.
> 
> 2) The connection then becomes proprietary (or you've got to come up
> with a host of standards and ports for use through the NAT for every
> possible appliance - we already have - in it's simplest form it's called
> IPv6) 
> 
> 3) The onus of contact behind a NAT relies on the hidden computing
> device.  That's why Red Hat users have to run a special daemon that
> connects out at regular intervals looking for updates. If Red Hat could
> initiate the contact with the daemon then it could push out any security
> updates immediately!  Your machine wouldn't be sitting there with a
> vulnerability waiting for the RHN daemon to kick off its daily look-see
> for anything new.
> 
> 4) If every household with a refrigerator wants to run the service
> (behind a NAT), we will quickly run out of IP addresses (6+billion
> households vs. 4.3billion available IP's from the current IPv4).
> 
> 5) NAT is not the only way to secure a device against being hacked or
> probed.  You can setup the same type of protection on your router - only
> now you'll have the greater security provided by the use of IPv6 (the
> packet can't be spoofed - you know its true source, or at least it's
> entry point onto the IPv6 internet).
> 
> 6) It's much easier to make a secure stripped down OS for an appliance -
> especially if the device's OS doesn't use RAM accessible to the data
> store.
> 
> 
> > 
> > The example given for the HVAC is a good one:  keep your HVAC inside the 
> > router on a 192.168 address.  When it needs to log into Train's web site 
> > (for example), it makes a connection.  Once the connection is made, the 
> > remote site can carry on a chat over the connection.  If it's REALLY an 
> > issue, there are plenty of unassigned ports.  Designate ports for each 
> > class of appliance and default routers to forward those ports.  Mind you, 
> > I still don't think it's good idea to have outside sources controlling 
> > what my inside devices are doing, but even in the above scenario, I still 
> > don't see a compelling reason to assign a real IP address to each device.
> > 
> > Maybe I'm missing the point here, but it still seems to me that we're 
> > better served by not putting everything on a real, publicly accessible, IP 
> > address.
> > 
> > William
> > 
> > On 21 Jan 2004, Jon Carnes wrote:
> > 
> > > On Wed, 2004-01-21 at 14:52, William Sutton wrote:
> > > > PMBIB,
> > > > 
> > > > Just why do we want things like toaster, refrigerators, and toilets to 
> > > > have their own IP addresses?  Why, for that matter, do we want digital 
> > > > cameras and pdas to have their own addresses?  Workstations, servers, 
> > > > printers, and networking gear I can understand, but appliances?
> > > > 
> > > > William
> > > 
> > > This is a good question, and I hope my answer is equally as good...
> > > 
> > > First of all there are some items that most folks really want on the
> > > internet - Mobile phones are a great example. Mapping systems in cars
> > > are another example.
> > > 
> > > And then there are appliances like say a Heating/Airconditioning
> > > system....  I see a time in the future when your HVAC system alerts you
> > > to a systems failure and checks to see if it's under warranty (and with
> > > who) then logs in to a dispatch center for remote diagnoses and
> > > scheduling of a repair roll.  You even pay a maintenance fee just so
> > > that all this happens in the background while you are at work; by the
> > > time you get home, everything is back up and running again.
> > > 
> > > You buy a TV from Best Buy, and you actually pay that hoky Maintenance
> > > Fee, and with that you get remote diagnosis of any problems on your set,
> > > and the local TV schedules downloaded to your TV every week.  You even
> > > get remote upgrades via the net, like picture within a picture or V-chip
> > > type filtering.  While you are at work you can monitor what your
> > > children are watching on TV - you can even change the channel and then
> > > lock it remotely (or simply turn it off and lock it with a pass code).
> > > 
> > > Your Refrigerator will come with a bar code reader and will connect up
> > > to your favorite grocery chain (Lowes Food).  When you run out of milk,
> > > you'll push the request button and then scan the old milk carton in
> > > (before tossing it in the recycle bin).  Your Trilug buddies are coming
> > > over on Thursday, you'll want to stock up on that beer that Jim likes,
> > > so you login to the Refrigerator and scroll through the past inventory
> > > picking out that special beer and a few other things to be added to your
> > > order.  On your way home from work the next day, you drop by your
> > > favorite food store and everything is already bagged up and waiting for
> > > you.
> > > 
> > > Your camera has a nice built in buffer and it can store up to a 100
> > > large shots, and when it gets a nice signal for internet access it logs
> > > in remotely to your PC and dumps those shots in the buffer out to your
> > > harddrive.  You never load film, and you don't mess with wire hook-ups
> > > to your home-based PC or your walk-about tablet. You just take pictures
> > > and enjoy them.
> > > The photo frame on your desk logs into your PC remotely and draws from
> > > the new pictures and displays them one at a time for ten seconds each.
> > > Your wifes photo frame picks up the same pictures and she scrolls
> > > through them with a few taps and then sends four of them off to
> > > Grandma's photo frame device.
> > > 
> > > None of these things is from the future. They exist now, but they need
> > > the infrastructure and security that comes with IPv6 in order to
> > > function properly.
> > > 
> > > Jon Carnes
> > > 
> > > 
-- 
Ryan Leathers <ryan.leathers at globalknowledge.com>
Global Knowledge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20040122/753d58ab/attachment.pgp>