[ipv6hackers] IPv6 security presentation at Hack.lu 2011
dotis at mail-abuse.org
Fri Sep 23 01:55:40 CEST 2011
On 9/21/11 11:48 PM, Fernando Gont wrote:
> Hi, Douglas,
> Thanks so much for your feedback! Please find my comments inline..
> On 09/21/2011 04:05 PM, Douglas Otis wrote:
>> The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
> Any particular reason for describing those? -- i.e., since it is a
> one-hour presentation, it's mostly a high-level overview, that only gets
> into some detail when needing to prove that something is more of a myth
> than a "fact".
Yes. DHCP is NOT required by IPv6 to support DNS. This impacts
security that depends upon DHCP snooping and should be mentioned.
Many expect a transition to IPv6 will not occur soon. However support
issues related with 6to4 caused a rethink by ISPs. The less painful
option is Dual-Stack Lite where ISPs deploy native IPv6 with centrally
controlled LSN where customers might share IPv4 addresses. This
increases a desire for IPv6 connectivity for improved security and freedom.
>> In Key areas in which further work is needed:
>> The statement 'Pushing people to "Enable IPv6" point-and-click style is
>> simply insane' is deceptive.
> While I might s/insane/incorrect/ (or the like), I do believe that
> enabling a technology that one doesn't understand is a really bad idea.
Even the assumption IPv6 is not enabled is a flawed concept. In
addition it would be appropriate to assume there WILL be an IPv6
firewall when IPv6 is enabled. Alternatively, it would be wrong to
assume any effective IPv6 firewall exists otherwise. Perhaps you could
replace "disable IPv6" with "disable Protocol 41" instead. :^)
> -- If whoever enabled v6 needed "5-step recipe to enable v6" or the
> like, then they probably should have been trained before enabling v6.
Again, the message should be that IPv6 _already_ exits within their
networks. Enabling IPv6 on the LAN permits better monitoring and
suppresses more problematic fallback strategies. The message should be
there is a need to monitoring this traffic NOW! Not enabling IPv6 on
the LAN only offers a false sense of security.
> IMO, this applies to *any* technology, not just v6, and is mostly
> orthogonal to how good or how bad are the security properties of that
> If you don't know "good enough" how your network works, attackers will
> probably do better.
Exactly. Any compromised system within a LAN can easily set up IPv6
connectivity, specifically because a lax approach was taken where not
enabling IPv6 was seen as offering improved security. :^(
>> It is wrong to suggest _not_ enabling IPv6
>> in a network offers improved protections.
> Well, I'd not say that it "provides improved protection", but rather
> than "does not increase risk".
Disagree. This view increases risks by offering the false concept that
relative inaction is better. By suggesting a NEED to enable IPv6 within
the LAN raises attention to the fact that IPv6 is already present and
the related risks MUST be mitigated or at least monitored. These risks
do not go away because IPv6 is not enabled. Instead these risks become
more difficult to monitor and the lack of monitoring gives malefactors a
field day. As it is now, everyday is a field day. :^(
> IPv6 (as any technology that you'd enable in addition to what you're
> already using), will add more pieces to the puzzle, increase complexity,
> and increase the number of potential vulnerabilities that could be
Complexity could be reduced by RAs announcing routes and RDNSS where any
AAAA records in DNS are filtered and any other IPv6 traffic is
black-holed. Even that effort will not stop malefactors from using
their own covert name services and IPv6 networks within a LAN where IT
"thought" IPv6 was disabled.
>> The statement 'Training is needed for engineers, technicians, security
>> personnel, etc., before the IPv6 network is running.' is also
>> deceptive. Unless extraordinary measures are taken which are also
>> likely to disable desired functionality, it would be wrong to suggest
>> IPv6 is not enabled in some fashion. IPv6 must be considered analogous
>> to that of a gun where security demands that it always be considered
> If I don't know how to handle a gun, I'd probably wouldn't have one in
> the first place. But if I *was* handled one, then I'd probably leave it
> as quite as possible, rather than start loading bullets and playing with
> the trigger, as if I knew what I was doing....
Internet connectivity IS a loaded gun. Inaction after "disabling IPv6"
is like leaving the safety off in the presence of children. Disabling
IPv6 on the LAN offers NO protection nor does it make maintaining
security easier. The natural reaction of the OS or application is to
then seek alternatives.
>> Those who feel protected by an IPv4 NAT should also consider trade-offs
>> needed to sustain peak loads. Often shortcuts that minimize overhead
>> also allow exploits.
> NATs do have some side-effect protections (albeit not bullet-proof,
> since technologies such as Teredo can be leveraged to break that
> assumption that "incoming connections are not allowed"). That said, I
> fully agree that NATs introduce a "single point of failure" in the network.
Please overcome misconceptions regarding NATs and IPv6. Whether IPv6 or
IPv4 is used, a LAN is vulnerable without SeND. Middle Boxes such as
NATs remove many protections otherwise possible. The LAN is vulnerable
whether through ARP spoofing, spanning tree or NAT table corruption,
etc. With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can
reverse the logical direction of connection setups. Even symmetric NAT
restrictions on undefined endpoints can be defeated by an unprivileged
compromised system through the use of broadcast MACs or techniques that
take advantage of exceptions that permit diagnostics.
Often applications don't notice when an SSL certificate fails to match
against a domain. Even with SSL, Middle Boxes offer easy MitM
exploits. It is absurd to describe NATs as offering improved
protection. Practices that depend on NAT "security" invite prone
systems that do more harm. IMHO, it is easier to firewall IPv6 than
deal with IPv4 related nonsense such as keep-alives, dynamic
translations, port mapping, etc.
> Whether the pros outweigh (security-wise) the cons (or not) depends,
> among other factors, where in the network the NAT box is. -- e.g.,
> glearly a CGN has many more negative implications that a NAT at a home
There are many compromised CPE routers. An ISP's LSN are not likely to
be any worse.
>> We have seen several high profile companies and
>> agencies where IPv6 offers covert channels for breached data by some of
>> the newer bot-nets. In several cases, the IT staff were unaware of
>> there being any IPv6 connectivity. In this light, these two comments
>> are poorly considered to say the least.
> The bottom-line is that you should make sure that your "assumptions" are
> correct. -- e.g., if you're argument for not applying specific v6
> technologies is that "my network is v4-only", you better make sure
> that's the case.
Assuring an assumption of "IPv4 Only" requires a sizable effort that
will prevent improved security from then being employed. :^(
>> Any NAT device within a network provides an easily exploited opportunity
>> for undetected MITM attacks. Only End-to-End security offers protection
>> from exploits related with ARP or ND+MLD where End-to-End security is
>> likely only possible with IPv6. This does not need to be IPsec.
> I cannot see why you argue that end-to-end security is only possible
> with IPv6.
It is possible to deploy SeND at Switches and routers without support of
the hosts. In this fashion, a far greater portion of the path can be
controlled where common LAN exploits can be avoided or detected.
>> In the further work needed section, perhaps a statement that RA resource
>> management flaws MUST still be corrected within affected hosts, such as
>> ignoring multiple headers or fragmentation to allow other OOB validation
>> methods whenever SEND is not available.
> Yes. Actually, I wrote to I-Ds to make an RA-Guard and ND-monitoring
> However, so far they are still "individual submissions", and that's why
> I didn't mention this as a possible solution that could be applied to
> solve these problems right now. But I agree that I should have
> notes/insisted that this should be pursued.
>> One might also add in further work section, the currently announced IPv6
>> size in conjunction with its exponential growth means use of source IP
>> addresses or prefixes alone are much less effective in attack mitigation
> When it comes to "filtering" as a mitigation for DoS, my take is that an
> IPv6 /64 corresponds to what we currently do with a single IPv4 address.
> Put another way, where in IPv4 you might be filtering a single IPv4
> address or a small prefix, in IPv6 you'd be filtering at least a /64.
> It would be worth adding, I agree.
The table size needed for such a strategy will likely increase in by a
factor of about 340,000 over what is used for IPv4 when only IPv6
prefixes are captured. Of course, this short-cut will disable entire
networks whenever someone forgets their password and tries too many
times. Not a practical defense strategy in many cases. IP address
related security must be replaced by certificates that can establish
white-listed address space for short durations. Perhaps wide spread
deployment of DANE with dynamic DNS updates is where this needs to
evolve. Without something like this, keeping up with a geometrically
increasing attack surface seems doubtful.
>> Just this prefix space is already more than 56,000 times
>> that of the entire IPv6 address space. Certificate based access should
>> be employed whenever possible might also be good advice.
> Ip address-based authentication is already well-broken with IPv4. (e.g.,
> I had mentioned that already when working on a sec assessment of v4
> <http://www.gont.com.ar/papers/InternetProtocol.pdf>). So I'm not sure
> anything changes in this respect when it comes to v6.
Some now hope in a new repute WG to base reputation on IP address
authorizations and message signatures that exclude who sent the message
and its intended recipient! This is another reason for mentioning
Dual-Stack Lite to raise security considerations that are related to
both the evolving IPv6 AND IPv4 address space.
And thank you for your valuable efforts.
More information about the Ipv6hackers