[ipv6hackers] Windows 7/2008 R2 Improved Resilliency to IPv6 Floods

[Jim Small]

Hi Fernando,

> > On Sun, Mar 31, 2013 at 09:55:17PM -0700, Doug Barton wrote:
> >> On 03/31/2013 09:09 PM, Jim Small wrote:
> >>> I have been testing some Windows 7 systems using Fernando and Marc's
> >>> tools.  With a system that's up to date in patches I haven't been able to
> >>> crash it.  The system is non-responsive during the attack, but when the
> >>> attack ends the system usually recovers fairly quickly.  Not always -
> >>> sometimes it takes a few minutes, but it still doesn't crash.
> >>>
> >>> I noticed from Sam Bowne that Microsoft released a new patch to
> improve
> >>> Windows 7/2008 R2 IPv6 stacks here:
> >>> http://samsclass.info/ipv6/proj/RA_flood2.htm#2
> >>>
> >>> From reviewing the KB here:
> >>> http://support.microsoft.com/kb/2750841
> >>> Issue #2 addresses some of the vulnerabilities - If you use many IPv6
> >>> address and IPv6 routes, the kernel memory is exhausted, and CPU
> usage
> >>> reaches 100 percent.  This update limits the number of advertised
> prefixes
> >>> and routes that each interface can process to 100.
> >>
> >> You might want to have a closer look at Issue #4 in that KB article, and
> >> the surrounding conversation about it. Namely if you have some sort of
> >> temporary interruption in your IPv6 connectivity at boot time you'll
> >> lose IPv6 for the lifetime of the session.
> >
> > to the best of my knowledge only a "positive" result of that query is cached
> (for 30 days) whereas a negative result leads to periodic re-trying.
> 
> Not sure what type of "failure" you're referring to. But I recall
> finding that, with many implementations (IIRC including FreeBSD), if DAD
> fails for the link-local address, that's "game over" for v6 until you
> reboot.

I haven't created a DAD failure for link-local, but for any GUA/ULA issues disabling/re-enabling the interface (unplumb/plumb) seems to fix the issues from my experience.  Specifically for this patch - this is Microsoft's implementation of Happy Eyeballs/RFC 6555.  Unlike Chrome for example which does a race between v6 and v4 giving v6 a 300ms head start, IIRC, Windows will check if the v6 "path" is valid.  If yes, it will prefer v6 (using Microsoft's modified 3484 policy - I don't believe they've picked up 6724 yet).  If no, it will prefer v4.  I think it then checks 30 days but I'm not clear on if it cache's failure results - curious if Enno tests and shares.  There was some controversy around how Microsoft choose to implement Happy Eyeballs but my understanding was they wanted a more deterministic approach (as opposed to what Chrome does).  I'm interested in the discussion Doug mentioned if he can dig up a link.

Here's the discussion of this feature for Windows 8 - note that the patch/KB above is backporting this functionality into Windows 7/2008 R2:
http://www.howfunky.com/2012/08/windows-8-and-ipv6.html


--Jim