Re: [v6ops] IPv6 transition technologies vs MITM (DEFCON)

David Farmer <> Thu, 22 August 2013 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA9CF11E8169 for <>; Thu, 22 Aug 2013 15:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mSf-XtsyvQGp for <>; Thu, 22 Aug 2013 15:59:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8A29111E813D for <>; Thu, 22 Aug 2013 15:59:27 -0700 (PDT)
Received: from ( []) by (UMN smtpd) with ESMTP for <>; Thu, 22 Aug 2013 17:59:21 -0500 (CDT)
X-Umn-Remote-Mta: [N] [] #+LO+TR
X-Umn-Classification: local
Received: by with SMTP id xn12so4885338obc.34 for <>; Thu, 22 Aug 2013 15:59:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tkWKlTQO5bOQFmedPn7BEFBueFjJOmKiYTCHX5xsEfA=; b=OI7BfMAWhjM8p2KoWXw/HKZgzxIsBzYnOcysZd70fEgXiRvt5rRcTyF4H8eppe1wIk srwAQRF8t3tilpvnuxlOq5OWwg6sRCcoZC6NgL5Rzdn5rlxPpL+2QRcXW5jVKgcg9Q2z rjTTO62hcfxS+NqnlgQZawTsoT/uzCLldTEJxXqHmooN1o/l+fQLqLlP3cm9SZhwfTbt rsyz2S6wjiwXxaS2bUu4eHCHxcyby0f/fQRnHwy5pp3+2IR81pBGTUS8t2dgDzS9WRf+ aGBnnC34g6GDkTbvZmd0QbbPWyYn5fAiFW0cYZdL5KyiHPcHiHD7v2yRcT1rA75qU7kD mM1A==
X-Gm-Message-State: ALoCoQk9scsMFGbpp5Gq2k7qdecAhPTToOohrI3v1WNQmB9JIeaXUCL4KQ/k9CzgYDeOB/9i3F+wkIjJCg9TEf/KjtszC6Q3+0tmXypDLygXSWQ7j8cEbqI7IyBtIOYwaTikyZREewP8
X-Received: by with SMTP id g1mr17093116oem.47.1377212360996; Thu, 22 Aug 2013 15:59:20 -0700 (PDT)
X-Received: by with SMTP id g1mr17093106oem.47.1377212360855; Thu, 22 Aug 2013 15:59:20 -0700 (PDT)
Received: from ( []) by with ESMTPSA id tz10sm21997856obc.10.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 15:59:19 -0700 (PDT)
Message-ID: <>
Date: Thu, 22 Aug 2013 17:59:18 -0500
From: David Farmer <>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Tim Chown <>
References: <> <> <EMEW3|aa8823c39ca54364e45099ae590c0046p7LLpN03tjc||>
In-Reply-To: <EMEW3|aa8823c39ca54364e45099ae590c0046p7LLpN03tjc||>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF v6ops list <>, Tom Perrine <>
Subject: Re: [v6ops] IPv6 transition technologies vs MITM (DEFCON)
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: David Farmer <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2013 22:59:33 -0000

On 8/22/13 15:51 , Tim Chown wrote:
> On 22 Aug 2013, at 19:51, Tom Perrine <
> <>> wrote:
>> But, what I'm seeing is that no one is talking about how the
>> transition strategies will not address this attack at all,
>> at least as far as I can tell. They all seem to seek to leave
>> (allegedly) IPv4-only nodes in place and work at one or
>> more hops away from those nodes. This ignores that so many nodes
>> really aren't IPv4-only. They are really dual-stack
>> nodes that are waiting for the IPv6 configuration to be completed. And
>> you can complete that configuration, or your
>> attacker will!
>> I see two ways to mitigate this attack:  turn off IPv6 on all modern
>> OSes, or fully deploy IPv6.  Guess which one I
>> don't want to see advocated :-)

Yes, deploying IPv6 is the best answer in many, if not most cases.  BUT;

>> Am I missing something, or is this one more point to add to the
>> "deploy IPv6 now, deploy native, skip the transition
>> technologies" ?  (I'm including dual-stack in the native strategy.)

I will expand on the references Tim provides below; On all IPv4 only 
networks you should operationally deploy RA-Guard or filter IPv6 ICMP 
RAs, and DHCPv6 server responses while you are at it too, on all access 
ports where you can, and more drastically filter Ether-Type 86dd all 
together where you don't have RA-Guard or IPv6 filters available.  In my 
view RA-Guard is not only a IPv6 network issue it an issue for all 
networks because of these MITM attacks.

Before World IPv6 day more than two years ago, we had a project to make 
our entire network quad-A safe.  That is we deployed IPv6 every where we 
could, and deployed IPv6 ICMP RA filters on virtually every wired access 
port.  We deployed IPv6 on our 802.1x authenticated wireless.  But we 
had to deploy 86dd filters on our web portal authenticated wireless, as 
the web portal didn't support IPv6, still doesn't, and there was no way 
to properly protect from Rogue RAs, other than to filter all IPv6 
traffic.  These generally weren't malicious MITM attacks, but were 
misconfigured hosts with Internet connection sharing turned on, but they 
still create issues on IPv4 only networks and would break any sites that 
would dare to use quad-As.

So, back to the big BUT above, it is naive to think you can deploy 
native IPv6 absolutely every where.  You may be able to deploy it most 
places, but you must protect from Rouge RAs every where, even IPv4 only 

For policy reasons, still today, we still haven't turned on IPv6 in 
several parts of our network.  These are mostly areas that deal with 
private data, HIPPI, FERPA, PCI and other compliance regimes, but it was 
extra important that theses areas also got RA-Guard for the very same 
reasons we haven't turned on IPv6 yet.

> There's lots of work within the IETF on this, e.g. take a look at
> The sunset4 WG is also quite interesting.
> I'm surprised an event like DEFCON presented something that old.

It's an oldie but goodie. :)

> Tim

David Farmer               Email:
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952