[ipv6hackers] Looking for feedback on subjective top list of IPv6 security issues

[Merike Kaeo]

On Mar 8, 2013, at 7:17 AM, Jim Small wrote:

> Hi Merike,
> 
>> What I always looked at from security perspective in difference between v4
>> and v6 are:
>> - multiple addresses per interface so which one gets used as SRC of packet so
>> that you can have effective access control at network layer (if you are trying
>> to provide access control in various parts of network for this)
> 
> Agreed - you better know 3484 cold.  My thought though is that should be part of an IPv6 operations talk?

The newer 6724 has already been pointed out but I think a statement worthwhile.  When things break, the implementations
that deviate could be a factor.  Operationally I always would want to know what not to overlook when troubleshooting issues.
(or testing devices to make sure they meet my needs....although for this I'd expect to refer to acredidation programs
since who has time to check for RFC conformance in all devices. This is where the UNH and TAHI and whatever other labs exist
are helpful).

And kudos to vendors to do have documents on how they deviate from some RFCs. (no comment on whether deviation appropriate :))

> 
> 
>> - extension header parsing which is hard in hardware at line rates if you are
>> late to the game and haven't paid attention
> 
> This is a major issue, but extension headers probably warrants an entire talk.

For all technical details on how they can be misused, yes.  However, just having folks take away that this is something to be aware of is useful.  The details you give depend on time.  
 
> 
> 
>> Then there is the fact that no matter how proactive you are with rate limiting
>> and filtering and effective cache management how are you observing
>> anomolies and detecting malicious traffic utilizing native or tunneled v6?  This
>> refers to effective auditing/logging which is hard enough in v4 environment
>> but how do you deal with this in v6?
> 
> Agreed - I will at least briefly discuss or through something in the appendix/backup slides.
> 
> 
>> There's also the email SPAM  black list issues which need to be rethought
>> (and there is ongoing work on this since for v6 environment...just follow
>> MAAWG work). For now it is expected that email servers will continue to use
>> v4 for a long time still which hopefully will buy some time until the solution is
>> solidified for how to handle v6 email SPAM.
> 
> Yes, E-mail is still a work in progress.  I'm trying to be encouraging with my talk though...is that wrong?  :-)

I don't know of any email servers that source email just using v6.  I asked at MAAWG which was 2 weeks ago and mostly
had ESP (email service providers) there.  I went to the BoF discussing bcp's for handling email on v6 and how to deal with
SPAM issues - this will not be a 'just do what you do with v4' since many SPAM blacklists are based on /32s.  

As the solutions to deal with v6 SPAM are still being designed and concensus worked on, I'd encourage people interested
in this issue to participate (or just follow) the work being done so that they are aware of the gotchas as they start looking to
deploy email solutions over v6 transport.

> There have been some BotNets using v6....can we detect them? Rhetorical
>> question here.  Need to be much more vocal on that so vendors start
>> creating tools that will be useful here.
>> 
>> Being proactive with security countermeasures is one thing but being able to
>> detect malicious behavior in v6 environment goes hand-in-hand.
>> Logging/auditing exception behavior effectively is critical.
> 
> I hate to say this on a security list, but I question how many organizations even do a decent job of this with IPv4...

Very few :)  Hence it needs constant visibility.  Most environments do not look at thresholds where some anomolous peak
happened and was just a 'blip' ..... in some cases this turned into a fullfledged sustained DDoS a few days/weeks later.  And these
are organizations that should know better.

But what's needed in v6 is even the detection capability which isn't always there.  It'll come....but we need to talk about it so that
vendors see there is some momentum of want/need for this.  

- merike