Re: subnet prefix length > 64 breaks IPv6?

[Ray Soucy <rps () maine edu>]

You will always be exposed to attacks if you're connected to the Internet.

(Not really sure what you were trying to say there.)
My primary concerns are attacks originated from external networks.
Internal network attacks are a different issue altogether (similar to
ARP attacks or MAC spoofing), which require different solutions.

As previously discussed in a recent thread, the attack vector you
describe (in a service provider environment) can be mitigated though
architecture simply by effective CPE design (isolated link network to
CPE, L3 hand-off at CPE, with stateful packet inspection; and small or
link-local prefixes for link networks).  Thankfully, this isn't a
model that is anything new; many networks are already built in this
way.

The only point contested is the validity of longer-than 64-bit
prefixes; which I think I've spoken enough on.

Enterprise and Data Center environments have a different set of
[similar] concerns.  Which is where the most concern on exploitation
of ND and large prefixes comes into play.  I think most of us have
been at this for long enough to have given up on the
one-configuration-fits-all school of network design.  A stateful
firewall internally can be a strong tool to mitigate this attack
vector in such environments, depending on their size.  For networks
where a stateful firewall isn't practical, though, that is where
stronger router implementation comes into play.

The suggestion of disabling ND outright is a bit extreme.  We don't
need to disable ARP outright to have functional networks with a
reasonable level of stability and security.  The important thing is
that we work with vendors to get a set of tools (not just one) to
address these concerns.  As you pointed out Cisco has already been
doing quite a bit of work in this area, and once we start seeing the
implementations become more common, other vendors will more than
likely follow (at least if they want our business).

Maybe I'm just a glass-half-full kind of guy. ;-)

I think being able to use longer prefixes than 64-bit helps
considerably.  I think that seeing routers that can implement ND in
hardware (or at least limit its CPU usage), and not bump known
associations for unknown ones will help considerably.  Stateful
firewalls (where appropriate) will help considerably.  And L2 security
features (ND inspection with rate-limiting, RA guard, DHCPv6 snooping)
will all help -- considerably.  Combined, they make for an acceptable
solution by current standards.

As was also pointed out, though, many networks don't even implement
this level of security for IP internally; the difference is that many
of them haven't needed to for external attacks because of the
widespread use of NAT, stateful firewalls, and much smaller address
space.  That is a little different in the IPv6 world, and why there is
concern being expressed on this list.

The most important thing is that network operators are aware of these
issues, have a basic understanding of the implications, and are
provided with the knowledge and tools to address them.

This really isn't much different than IPv4.




On Wed, Dec 28, 2011 at 4:08 PM, Jeff Wheeler <jsw () inconcepts biz> wrote:
> On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy <rps () maine edu> wrote:
> > There are a few solutions that vendors will hopefully look into.  One
> > being to implement neighbor discovery in hardware (at which point
> > table exhaustion also becomes a legitimate concern, so the logic
> > should be such that known associations are not discarded in favor of
> > unknown associations).
>
> Even if that is done you are still exposed to attacks -- imagine if a
> downstream machine that is under customer control (not yours) has a
> whole /64 nailed up on its Ethernet interface, and happily responds to
> ND solicits for every address.  Your hardware table will fill up and
> then your network has failed -- which way it fails depends on the
> table eviction behavior.
>
> Perhaps this is not covered very well in my slides.  There are design
> limits here that cannot be overcome by any current or foreseen
> technology.  This is not only about what is broken about current
> routers but what will always be broken about them, in the absence of
> clever work-arounds like limits on the number of ND entries allowed
> per physical customer port, etc.
>
> We really need DHCPv6 snooping and ND disabled for campus access
> networks, for example.  Otherwise you could give out addresses from a
> limited range in each subnet and use an ACL (like Owen DeLong suggests
> for hosting environments -- effectively turning the /64 into a /120
> anyway) but this is IMO much worse than just not configuring a /64.
>
> On Wed, Dec 28, 2011 at 10:45 AM,  <sthaug () nethelp no> wrote:
> > I'm afraid I don't believe this is going to happen unless neighbor
> > discovery based attacks become a serious problem. And even then it would
> > take a long time.
>
> The vendors seem to range from "huh?" to "what is everyone else
> doing?" to Cisco (the only vendor to make any forward progress at all
> on this issue.)  I think that will change as this topic is discussed
> more and more on public mailing lists, and as things like DHCPv6
> snooping, and good behavior when ND is disabled on a subnet/interface,
> begin to make their way into RFPs.
>
> As it stands right now, if you want to disable the IPv6 functionality
> (and maybe IPv4 too if dual-stacked) of almost any datacenter /
> hosting company offering v6, it is trivial to do that.  The same is
> true of every IXP with a v6 subnet.  I think once some bad guys figure
> this out, they will do us a favor and DoS some important things like
> IXPs, or a highly-visible ISP, and give the vendors a kick in the
> pants -- along with operators who still have the "/64 or bust"
> mentality, since they will then see things busting due to trivial
> attacks.
>
> --
> Jeff S Wheeler <jsw () inconcepts biz>
> Sr Network Operator  /  Innovative Network Concepts



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/