[ipv6hackers] Looking for feedback on subjective top list of IPv6 security issues
jim.small at cdw.com
Sun Mar 10 02:10:26 CET 2013
> 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.
> 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
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.
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...
More information about the Ipv6hackers