[ipv6hackers] Looking for feedback on subjective top list of IPv6 security issues

[Jim Small]

> On 09.03.2013 19:50, Jim Small wrote:
> >>> 9)      MLD/MLDv2 attacks - I'm not very clear on dangerous attacks
> >>> for this one...
> >>
> >> I can shed some light here.
> >> many router implementation suck here. flood them with random
> >> report/done
> >> messages, or mld router advertisements/solicitation and you get 100%
> >> cpu, 100% ram and/or crash.
> >> even with firewalls (netscreen for example. uh, just remembering I never
> >> told them that. because their security team was not interested in fixing
> >> ipv6 bugs so I stopped telling them)
> >
> > I would definitely like to know more here.
> > MLDv2 is the default though so to even consider convincing people to
> > "downgrade" to MLDv1 I feel like I'd have to have a lot more evidence.
> > I'll keep looking at this.  I did go through the RFCs and I see what
> > Fernando means about MLDv2 being much more involved.
> 
> well, I think Fernando is saying "do MLDv1 instead of MLDv2" simply
> because MLDv1 is a very simple message, whereas MLDv2 is way more
> complex which increases DOS attack vectors, general higher likelihood
> for bad parser implementation etc.
> 
> In my opinion multicast is a very cool thing and can be very useful.
> sadly, to harden it against attacks, from design to configuration to
> implementation is very, very hard.

You're right.


> Therefore I personally would recommend to avoid any ff05:: multicast
> stuff unless you have all areas secured down and under control.
> basically: if trust everyone within the multicast domain.
> 
> doesnt sound like that in what you describe as the planned usages ;-)
> 
> Well, getting back to your question - with all the things in multicast
> that can be problematic or hard to secure, recommending MLDv1 vs MLDv2
> does not gain much. So I'd say, go with MLDv2.

I continue to look at this but I agree multicast decisions should be made carefully.

 
> >>> 11)   Extension header attacks - this one is especially tough,
> >>> probably lots more to find...  I especially like Marc's warp packets
> >>> with the router alert "high speed tag" which also double as ACL
> >>> bypass agents.
> >>
> >> yeah, that was so much fun ... :-)
> >> actually I did not find a lot of issues here. as there are not that many
> >> options yet, this is rather limited.
> >> but fragementation headers plus extension headers - thats where it gets
> >> scary (one of many examples, see my report on the Kaspersky remote
> >> freeze).
> >
> > There are two issues I see here.  Fragmentation and the fact that many
> > systems can't filter/parse/inspect extension headers.  Many security
> > systems are only designed to deal with a single L2 header and a single
> > L3 header.  If you stick a bunch of extension headers in the middle
> > they just ignore them.  I find this disconcerting and have been
> > pushing for better options.
> 
> I havent come across such things for quite some time now.
> Agreed it was a problem, I remember the old ndpmon implementation.
> Do you have information on affected products/tools that are "current"?
> I can't believe I am arguing "pro" here ;-)

I know of many "enterprise-grade" commercial firewalls that are IMHO unsatisfactory with their current IPv6 extension header capabilities.  I would like to see a firewall be able to arbitrarily block any extension header by number regardless of where it is in the chain or regardless of fragmentation.  I would also like the ability to parse/inspect any extension header with the same criteria - regardless of where it is in the chain and regardless of fragmentation.  There are definitely some capabilities here, but not as much as I would like.  I really like pf and netfilter/iptables but I haven't really done an IPv6 deep dive with these.  Do they have these capabilities already?  Does snort or suricata?


> >> Either go IPv4 only (means: disabling IPv6 everywhere)
> >
> > I don't see how to do v4 only.  Organizations need parts of their
> > networks running v6 to develop operational experience.  Developers need
> > v6 to develop and test mobile/web applications for v6.  I can see limiting
> > v6 within a network but I don't see how to do v4 only.  If an organization
> > stays v4 only until say 25% of the Internet is running v6 then they will
> > have no security/operational v6 experience.
> 
> I do not agree to this. products are still inmature. deploying when its
> still bleeding edge gives you experience, yes. but also a lot of
> trouble, also security ones.
> When you join late, yeah, you are missing experience. but good, mature
> products, training for your staff, and external consultants who know
> whats imporant make it an even easier and more painless experience.
> 
> but of course - somebody must start, otherwise nobody will ever deploy.

That's the point of the conferences - present there, present at user groups, share best practices and promote a smart, steady ramp up.


> >> or IPv6 only
> >
> > I also don't see how to make this work.  Most companies have legacy
> > v4 systems like embedded/controls/SCADA-type systems that may never
> > do v6.  Take a look at almost all training and network related
> > material.  Everything is "IPv4-only."
> >  I think trying to switch to v6 only is too much.  In a network
> > centric crowd you have a general awareness of IPv6.  However,
> > ask systems people, developers, or the virtualization crowd about IPv6.
> [...]
> > However, I can't see this working for a typical enterprise/organization.
> > Do you think I'm way off here and missing the bus?
> > Marc, I know you do a lot of consulting - have you seen these
> > approaches work for your clients?
> 
> I'd say you are right on the spot. however there a lot of small fresh
> companies who could go directly IPv6 only without major issues.
> Dual stack is a bag of snakes. I'd recommend to avoid it as much as
> possible, and rather build a translation segment and gradually move
> equipment vom the ipv4 network to an ipv6 network.
> But in some scenarios thats unfeasible. In these I'd recommend to either
> stay IPv4, and do dual stack and curse your job :-)
> 
> (but I am not an IPv6 consultant. I do security research and analysis
> for clients, also in the field of IPv6. In the IPv6 projects I was so
> far, I take care of good policies, equipment testing, pentesting, etc.
> And I ask "is IPv6 really necessary for you?". But I will never organize
> a migration myself. not my field of expertise. I only can say from the
> issues I have seen, that dual stack is good for people who need job
> security)

Running a multi-protocol network is a pain.  But we did it for DECNet, IPX, AppleTalk, and others.  We'll manage.  I agree the goal needs to be to get to IPv6 only but I don't think most people are ready for that yet.  At least not from what I've seen.  Give it time.

 
> And maybe to add to this: I have no clear vision how the start to move
> to IPv6 in the next 2-4 years can actually happen.

One person, one organization at a time.  That's why we're all here, to help everyone make the move.


> Nearly every company will need external know-how. OK, more and more
> consultants get IPv6 knowledge, but as such projects tend to take 6-24
> months (depending on network size, complexity and application
> readiness), there can not be enough consultants on the market for this
> by that time. And of course its a high cost factor for companies too
> (not to mention the training for the people who need that. license cost
> for software upgrade. new hardware. overtime required for the migration.
> etc.).

I am trying very hard to promote a steady ramp up.  Critical mass will most likely happen in the US in late 2014/early 2015.  That's when the killer apps will start.  My hope is that we have rough consensus on best practices and reasonable security by then.  One can only hope...

--Jim