[ppml] IPv6>>32

[Leo Bicknell]

In a message written on Tue, May 10, 2005 at 11:05:19AM -0700, Tony Hain wrote:
> You appear to be focused on absolute utilization efficiency. CGA approaches
> like:
> http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht
> m
> trade space efficiency for authenticity. Approaches like using RFC3041
> addresses for everything trade utilization efficiency for immunity to
> scanning attacks. 
> 
> Maximizing allocation efficiency is simply one dimension in a
> multi-dimensional problem space. 

There are several problems I have with functions like CGA, and some
of the current thoughts on host address space.  In no particular
order:

The current IPv6 policy allows for a /128 where "one and only one"
device will be connected.   This is an Achilles heal for the entire
class of new host based addressing schemes.  First and foremost, if
an application is to work in this situation, it must be capable of
working from a single address.  An application vendor would be
foolish to write an application that only worked where multiple
addresses were available, locking them out of a segment of the
market.  A secondary problem is that for all the various security
through obscurity machinations about cryptographically picking
addresses and / or being unable to scan a 64 bit address space if
a host has a single address, and a single address only it's likely
that it has a limited ability to change address, and also it is
more likely that address will be known to at least some entities.
This makes relying on any sort of "security" offered by the wide
address space at best a foolish proposition.

For that matter, who's to say that 64 bits of space can't be scanned?
Sure, it can't be exhaustively scanned anytime in the near future,
but the people don't the scanning don't need exhaustive scanning.
All a virus, worm, or attacker needs is one vulnerable host.  Quite
frankly, the more addresses a box uses, the worse this problem
becomes.  A box using 100 addresses, is 100 times more likely to
be hit by a partial scan.  Once a single host on a subnet is
compromised the rest will be found via other means.  Multicast,
broadcast, higher level functions from rwho to Rendezvous will be
used to find other hosts.

That's not to say I believe the bar isn't raised.  I think the bar
will be raised.  However, earlier someone used a balloon analogy,
and I think that's quite appropriate here.  Squeeze one side of it,
that is making scanning harder here, and the attacks will simply
pop out another vector.  That's a good thing, isn't it?  Well, not
really in an address.  See, what's happened here is we're giving
away bits that don't solve a problem, but we're incurring the direct
cost of the overhead in transmission and memory to store information
in routes and other devices, and the opportunity cost of using them
for something else, like routing.

There's also a more basic layering problem.  The lower down in the
protocol stack a problem exists, the harder it is to fix, and the
more wide spread the impact.  Embedding information other than what
is necessary to get a packet to its destination in the layer who's
sole responsibility is getting the packet to its destination is
extremely dangerous.  Embedding things like crypto in basic addressing
implies some level of awareness at the deepest levels of the IP
stack.  Any errors in coding, performance impacts, or security flaws
will have a devastating impact.  The network system is built out
of layers for a very good reason.

Let's directly address CGA.  CGA exists because IPv6 has fundamental
security flaws.  Rather than design a secure protocol from the
start, an insecure protocol was offered up, and now people are
trying to bandaid a solution, using any free bits they can find.
I suppose in some twisted sense that qualifies as "innovation".
Most interesting to me, is that CGA addresses the wrong problem.
They talk about WiFi networks, and making sure you're talking to
the correct router.  The problem is, all CGA tells you is that
you're talking to the person who sent you a reply.

Again, the attack vector shifts, but only slightly.  The simplest
description is this: Go to starbucks, fire up a WiFi jammer on the
frequency used by the in-house WiFi.  At the same time, turn up a
new network with the same name and such on a new frequency, using
a cellular modem to gateway traffic to the internet.  Provide service
to everyone in the Starbucks.  A user goes in, turns on their computer,
is connected to a WiFi network with the right name, and your own
rogue box can even do CGA proving it is who it says it is.  The user
browses the web just fine, with all the traffic going through your
box.  Again, raised the bar, and yet completely missed the security
mark.

Of course, the reality is, why would an attacker care?  An attacker
would be stupid to put his system in the middle of communications on
a WiFi network.  There's no need.  Passive sniffing yields all the
information, causes no performance issues, and when done properly
is completely undetectable.  Triple padlocks on the front door don't
change the fact that the garage is wide open....but it will keep
people from going in the front door.

Will the bits be used?  I have no doubt that if they are available
someone will "innovate" and use them for something.  Is that a good
use of the bits?  Absolutely not.  Layer 3 is about the information
in a packet necessary to get it to its destination.  Anything else
should be in a higher level.  Other items put there are dangerous.
They destabilize the system.  Applications, and make no mistake,
proposals like CGA is an application, will only grow over time.
Security requires more bits.  Features require more bits.  They
will either outgrow the bits allocated, move on, and leave them
wasted or worse, they will demand more bits in the next system.

So no, I'm not sold that putting anything other than an address,
that is, the information needed to get a packet to its destination
in the "address field" is a good idea.  Indeed, I think the opposite.
It's playing with fire, and particularly if exploited the wrong way
early on will be yet another reason IPv6 will not be adopted.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050511/f1db5297/attachment.sig>