Re: drafty IPv6 security overview draft submitted

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Thanks for comments.

Sorry for not being to answer right away..

On Fri, 20 Jun 2003, Alain Durand wrote:
> A couple points:
> 1- You do not talk about the tunneling/open relay issues,
>       like the abuse of 6to4. those were discussed elsewhere,
>       but I think it would be worth it mentionning them here.

The reason why I left them out (mostly: I only said that transition 
mechanism security has to be considered, in general) is that I don't want 
to try to tackle the same issue many more times.

In this particular case (6to4), I think it has been rather well 
documented.  Did you have some others in mind?

Of course, it might be a good idea to try to add some kind of summary of
the discussion here, or some brief words at least.  Only, I'm not sure if
there is an agreement on how to summarize it (at least yet).

> 2- I came across an interesinting issue when playing with VPN:
>      I use an IPv4 VPN to connect to my office network.
>      My DNS resolution is done over IPv4.
>      When I'm looking for my server, the DNS (over IPv4 over VPN)
>      returns both A and AAAA records. When my laptop is on an IPv6
>      enable link, it will use IPv6 to try to connec to my server.
>      However, the VPN does not know about IPv6, and it let the packets
>      go on the local network. Anybody on the
>      local link can intercept those packets by pretending to have the IPv6
>      address of my server (thanks to neighbor discovery, it does not even
>      have to compromise any router...).
>      This may be a bug in my VPN, bit I wonder how many VPNs share
>      the same behavior...

I think this stems from even a bigger issue about Neighbor Discovery.  
Consider an IPv6-enabled node in any network at all, where IPv6 routers
don't exist, and a transition mechanism isn't available (there are a
*plenty* of those).

The same attack is still possible.

This stems from the ND principle of assuming all destinations are on-link 
unless you know otherwise.  This has caused problems in the past too.

I personally don't think this is a big issue as such, as in IPv6 protocol 
suite there is an assumption that your link is relatively secure.  But it 
might make sense to bring it up explicitly so folks don't forget about it.

It might make sense to kickstart some effort (this and potential issues 
unearthed in the v6-on-by-default come to kind) to record the issues 
encountered in Neighbor Discovery specs (as those are bound to be revised 
soonish).

Thanks.

> Pekka Savola wrote:
> 
> >Hello all,
> >
> >I just submitted a draft on IPv6 security overview.  It's quite raw 
> >and badly structured, but I ran out of time (and I'm off for a few 
> >days, back on Wednesday or so).
> >
> >I've tried to describe at least briefly all the aspects relating to IPv6 
> >and IPv6 transition/co-existence I could quickly think of.  This could be 
> >one basis for the security discussion in Vienna.
> >
> >Please have a look at it at some point and send feedback.
> >
> >Prior to it being formally posted, it can be read from:
> >
> >http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security-overview-00.txt
> >
> >Abstract
> >
> >   The transition/co-existance from IPv4 to IPv4/IPv6 causes one to
> >   consider the security considerations of such a process.  In this
> >   memo, I try to give an overview of different aspects relating to
> >   IPv6: the notion of increased end-to-end transparency, implications
> >   of tunneling, the use of IPv4-mapped addresses, the considerations of
> >   IPv6 service piloting without firewalls, IPv6 protocol-specific
> >   issues, IPv6 transition/co-existence mechanism -specific issues,
> >   consequences of enabling IPv6 by default, and operational security
> >   issues when enabling IPv6 in the network infrastructure.
> >
> >
> >It's only about 8 pages or so :-)
> >
> >  
> >
> 
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings