[ipv6hackers] IPv6 security presentation at Hack.lu 2011
dotis at mail-abuse.org
Wed Sep 21 21:05:52 CEST 2011
On 9/21/11 10:10 AM, Fernando Gont wrote:
> Folks, We have uploaded the slides of the IPv6 Security talk I gave at
> Hack.lu 2011. The slides are available at:
> If there are any topics in the slides that that you think might
> benefit from debate/discussion/brainstorming, please feel free to post
> to the list.
Here are a few immediate reactions.
The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
Security Implications of Transition/Co-existance Mechanism should also
mention Dual-Stack Lite (RFC6333) along with Port Control Protocol (PCP)
NAT-PMP Interworking Function.
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. It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.
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 loaded.
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. 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.
"Always consider a network to have IPv6 connectivity and take steps to
security it." would be better advice.
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.
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.
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
strategies. 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.
More information about the Ipv6hackers