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

[Marc Heuse]

Hi Jim,

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.

>>> 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 ;-)

>>> 12)   Tunnel attacks - I think the only interesting ones would be
>>> those against 6in4, ISATAP, and 6rd as IMHO those are the only ones
>>> that are in use.  I have read about tunnel attacks but haven't played
>>> with this very much.  Do you think this is a serious threat worth
>>> covering?  Any suggestions on tools?
>>
>> if you use them and want security, you have to secure them with IPSEC.
> 
> With 6in4/6rd over the Internet this typically isn't an option.

yeah, but in end-user cases you do not need the ipsec security.
only those who must trust what comes out of the tunnel - they have to
use ipsec. companies doing site-to-site 6to4.
internet users can not trust anything coming out of the tunnel same as
anything coming in via IPv4 through their DSL connection :-)

>> I agree with Fernando that another important vector is the VPN dual
>> stack leakage issue. However I would expand on this and say that any
>> IPv4-only-thought-of network and dual stack networks pose a risk as the
>> complexity increases massively when both a present in the same network.
>> 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.

>> 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)

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.
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.).

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A