[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Fernando Gont]

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
> options.

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".



> ---
> 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.
-- If whoever enabled v6 needed "5-step recipe to enable v6" or the
like, then they probably should have been trained before enabling v6.

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
technology.

If you don't know "good enough" how your network works, attackers will
probably do better.



> 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".

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
exploited.


> 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.

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....



> 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.

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
router.


> 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.


> 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.


> 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
mitigations:

* <http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt>
* <http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt>

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
> strategies.  

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.


> 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.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492