NIST IPv6 document

Thu Jan 6 03:42:25 UTC 2011

> From: Dobbins, Roland 
> Sent: Wednesday, January 05, 2011 7:19 PM
> To: Nanog Operators' Group
> Subject: Re: NIST IPv6 document
> 
> 
> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote:
> 
> I don't believe that host-/port-scanning is as serious a problem as
you
> seem to think it is, nor do I think that trying to somehow prevent
host
> from being host-/port-scanned has any material benefit in terms of
> security posture, that's our fundamental disagreement.

It will be a problem if people learn they can DoS routers by doing it by
maxing out the neighbor table.

> If I've done what's necessary to secure my hosts/applications, host-
> /port-scanning isn't going to find anything to exploit (overly-
> aggressive scanning can be a DoS vector, but there are ways to
> ameliorate that, too).

I don't think you are understanding the problem.  The problem comes from
addressing hosts that don't even exist.  This causes the router to
attempt to find that host.  The v6 equivalent of ARP.  At some point
that table becomes full of entries for hosts that don't exist so there
isn't room for hosts that do exist.

> This whole focus on sparse addressing is just another way to tout
> security-by-obscurity.  We already know that security-by-obscurity is
a
> fundamentally-flawed concept, so it doesn't make sense to try and keep
> rationalizing it in various domain-specific instantiations.

No, it was designed to accommodate EUI-64 addresses which are to replace
MAC-48 addresses at layer2.  We currently create an EUI-64 address out
of a MAC-48 in many cases during SLAAC but at some point the interfaces
will be shipping with EUI-64 addresses.  The world is running out of
MAC-48 addresses.

So at some point the "MAC" address will be the host address and it will
be 64-bits long.  It has nothing to do with "security by obscurity".