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

[Jim Small]

Hi Marc,

> > 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.  Multicast is becoming increasingly common, at least in the US anyway.  I know there have been several comments that it's only used for ND so let me provide some examples of how I see it used.  Universities and Hospitals frequently use it for Video.  It is also widely used for UC (Unified Communications) such as music on hold, paging, and again video.  Digital signs frequently use/require multicast for content distribution.  Financial services use it for their trading tools.  A good question however, is how much is SSM used?  My understanding is that's the driver for IGMPv3/MLDv2.  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.


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

 
> > 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?
> 
> gladly I see little use of tunnels.

I agree that tunnels are completely undesirable.  Unfortunately it is still common that native IPv6 service is not obtainable so for residential access you're stuck with either 6rd or 6in4.  For business access you're stuck with 6in4.  Many large companies have legacy equipment that they're not willing to just refresh so you can be stuck using ISATAP or 6in4 to tunnel "around"/through legacy equipment.  So my concern is feeling more confident about the vulnerabilities tunnels introduce.  I know some of them but feel like I have more to learn here.


> and the risk is limited if you give
> what comes out of the tunnel no trust.

That definitely makes sense.


> 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.  Internally there are some cases where you could do 6in4 over IPsec, v6 over IPsec, or v6 over GRE over IPsec.  For ISATAP IPsec isn't practical/scalable.  Would be nice to have an open any-to-any IPsec like solution for both unicast and multicast (something like Cisco's GET VPN) but I am unaware of anything like this for general purpose operating systems.


> 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.  When they finally enable v6 they will be far behind on requisite experience/security while attackers will be proficient.  Doesn't this actually make things worse in the long run?


> 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 still remember teaching networking - I'd have lots of confident students until we got to IS-IS.  Then I'd have lots of lost students.  Many people have no idea that they don't really understand networking, but only IPv4.  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.  I can see it for a carrier where they can have a much higher level of expertise then a typical enterprise.  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?


Thanks again for the feedback,
  --Jim