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

[Jim Small]

> > On 10.03.2013 02:10, Jim Small wrote:
> >>>>>> 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.
> >>>
> >>> 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 am just now reviewing four different firewalls for the IPv6
> > capabilities for a german magazine.
> > useful filtering on extension headers - only Cisco ASA can do this with
> > their newest firmware.
> > Filtering on options: nobody can do this at the moment. and this is
> > important (but also for an admin not very feasible to also know and make
> > good decisions about. I was told ASA can should be able to do that at
> > the end of the year. But lets see.
> 
> Dave Piscatello had done a fairly comprehensive v6 firewall survey about 2-3
> years ago
> and was just appalled at state of things.  I'd love to compare what you are
> doing to what
> was found a few years back (I'm fluent in German btw so a pointer to article
> once available would be great)

There is much work to be done for commercial firewalls.  Maybe we should have a check list?  So from my testing I can tell you that we are quite a ways from full feature parity.  So just from the start you need to figure out what's missing on the IPv6 side.  Things to focus on:
* Go through NIST SP800-119 - it's a great start on what to look for and a great read.
* IPv6 Only setup - can you configure, manage, and monitor the firewall only using IPv6?  Many solution can't even get this far.
* For any hardware acceleration - is it the same with v6?
* For application/protocol inspection engines there should be full parity for v6.  AFAIK, no firewalls have yet achieved this.
* For policy setup are v4 and v6 handled separately or as one unified policy?  The latter seems to be the trend.  This makes things a little easier or at least seems to.  The tricky thing though is that v4 and v6 are ships in the night so unified policy management only creates the illusion of unified access control while in reality the control planes are separate.  This concerns me a little.
* Does the solution support DHCPv6 relay?  DHCPv6 server?  DHCPv6 prefix delegation? (Do any firewalls support this yet?)
* Does the solution support NAT64/46?  NAT66?  NPTv6? (I think only netfilter/iptables supports this)
* For all support protocols are they supported on v6?  Syslog/NTP/RADIUS/TACACS+/NetFlow?
* For all supported routing protocols are they supported for v6?  RIP/OSPF/EIGRP/BGP?
* For all troubleshooting tools are they supported for v6?  ping/traceroute/tracing tools/etc?  For each tool can you control whether it uses v4 and/or v6?
* For access control can the firewall selectively drop a packet based on any arbitrary extension header number regardless of where it's at in the header?  Make sure it's not just the first 6 (AH/ESP/Dest-Opt/Fragment/HBH/RH).  I think USGv6 only requires these.  But what about for example the mobility header or other new/experimental headers?  That's why firewalls should allow you to match on any EH number.
* Many EH have sub-options so the firewall should also allow inspection/parsing on all EH and dropping based on flexible criteria.  For example, maybe I want to allow the HBH header but not if it's a jumbogram.  The firewall should allow this level of granularity.
* The firewall should allow TTL inspection and actions (like dropping) based on this.
* Validate that the firewall can match/inspect EH regardless of whether they are in the first packet or not.  Many firewalls can have their policy bypassed if the EH isn't in the initial header (as Marc has observed) and I can also confirm.
* For VPN the firewall should support v6 only for IPsec site-to-site/remote access (and should also be IKEv2/ESPv3 based) as well as for "SSL" VPNs.  Ideally the firewall allows 4in6/6in4/4in4/6in6 for both IPsec and "SSL."

I think that's a decent start - any other big ones I'm missing?


> I have heard that some folks are asking vendors to create capability to drop
> packets if they have more
> than 'X' extension headers - not sure when that functionality will ship but this
> is a good practical feature.

Agreed - this should be a mandatory feature and I can confirm that some vendors already support this in shipping code.


> I had a good conversation with Fernando today since we're both in Orlando
> for IETF.  I am super
> happy more people are helping educate and creating tools to help folks
> create more resilient v6 deployments
> (I am avoiding 'more secure' on purpose).

I'm envious, good luck with moving Fernando's drafts forward!  :-)

--Jim