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

[Jim Small]

Hi Karl,

> On Sun, 2013-03-17 at 22:05 +0000, Jim Small wrote:
> > You got me curious.  I setup Ubuntu Desktop 12.10.  On that release
> > (fully patched), the default prefix policy table doesn't implement RFC
> > 6724:
> 
> It does mostly. The 6Bone and site-local stuff is missing, yes.
> Different label values don't matter as long as they are all different,

Agreed.


> different preference values only matter if they would order the prefixes
> differently.

Exactly, this is the problem.  If you look at 6724, the labels stay the same but the precedence changes.

3484 default:
Prefix        Precedence Label
::1/128               50     0
::/0                  40     1
2002::/16             30     2
::/96                 20     3
::ffff:0:0/96         10     4

6724 default:
Prefix        Precedence Label
::1/128               50     0
::/0                  40     1
::ffff:0:0/96         35     4
2002::/16             30     2
2001::/32              5     5
fc00::/7               3    13
::/96                  1     3
fec0::/10              1    11
3ffe::/16              1    12
Note:  Labels are not in order of precedence.

Diff from 3484 to 6724:
::ffff:0:0/96 precedence changes from 10 to 35 - this gives it priority over 6to4, Teredo, ULA, Site-Local, and 6bone
::/96 precedence changes from 20 to 1
2001::/32 - Teredo is new
fc00::/7 - ULA is new
fec0::/10 - Site-Local (deprecated) is new
3ffe::/16 - 6bone (deprecated) is new

>From looking at my Ubuntu 12.10 installation, some of the prefixes have been added but the precedence hasn't been changed.  Given the importance of changing the precedence for ::ffff:0:0/96 (IPv4 mapped IPv6 address) or all IPv4 space I'd call this significant.


> It is extremely easy to change /etc/gai.conf so that it is
> 6724 compliant if you want that - just edit it with a text editor (but
> see below).

Agreed.


> > Also, how do you view precedence for the Linux prefix policy table?
> > The command "ip addr showlabel" only shows the prefixes and labels but
> > not the precedence.
> 
> I don't know, but you can literally just read /etc/gai.conf for the
> precedences (see below for why). If you find a way to get the info
> direct from the kernel, do tell us.

LOL - nothing has changed since the early UNIX days.  I have the source code, what else do I want?  :-)


> > He mentions gai.conf but I'm still not completely clear on how
> > updating this works.  Do you have to reboot for the system to use an
> > updated version?
> 
> No, you do NOT have to reboot the system, because rebooting the system
> does precisely nothing as far as /etc/gai.conf and the precedence and
> label tables are concerned :-)
> 
> It's a bit tricky; I do talk about it in my blog entry though
> (http://biplane.com.au/blog/?p=122).

Thanks - I read it and I have to say that sucks (the situation not your blog!).  So there isn't a way to universally modify the prefix policies in Linux?  And there's no exposed userland command to set precedence?  Not only does that draw wind deeply but it will make managing Linux systems somewhat challenging if you want to comply with 6724.

In Windows both the precedence and label for the prefix policies can be viewed/modified using netsh.  I recently ran into a situation where I had a system with both public and ULA v6 addresses.  I wanted the system to use the public address for a specific destination and from going through the address selection rules I thought it should.  But it used the ULA causing firewall problems.  Refer to Enno's sage advice in his preso.  Anyway, I fixed it by adding a new prefix policy which covered the /48 I'm using.  I thought this was lame though so I removed it and tried change my prefix policy table to match 6724 and voila - it fixed the issue!  So there's got to be a way to do this in Linux.

For example, to make a Windows system comply with 6724 you can use the following (assuming starting from the default which is pretty close to 3484):
netsh int ipv6 set prefixpolicy ::ffff:0:0/96 35 4
! Note - Windows can't deal with a prefix smaller than a /8 - if you add fc00::/7 it doesn't work.  So you have to split it into two /8s.  :-(
netsh int ipv6 add prefixpolicy fc00::/8 3 13
netsh int ipv6 add prefixpolicy fd00::/8 3 13
netsh int ipv6 set prefixpolicy ::/96 1 3
netsh int ipv6 add prefixpolicy fec0::/10 1 11
netsh int ipv6 add prefixpolicy 3ffe::/16 1 12

View the prefix policy table:
netsh int ipv6 show pref


> Firstly, as far as I can tell, /etc/gai.conf is *completely ignored* as
> far as label information is concerned. That is, it is not used at boot
> time or any other time.
> 
> *Precedence* information is read out of /etc/gai.conf (if present) the
> first time a process needs it, and thereafter it uses whatever it read
> the first time. That is, it is per-process and isn't read at boot time
> (except by processes that happen to run at boot time, of course).
> Processes can be told not to cache the information by saying "reload
> yes" in /etc/gai.conf. Since changes to /etc/gai.conf are going to be
> rare - probably VERY rare - it makes sense not to worry too much about
> this, and I strongly recommend you do NOT use the "reload" option,
> because that will means very frequent unnecessary file access just in
> case, once in a blue moon, the file actually changes. If you have very
> long-running processes, you should probably just restart them if you
> change the precedences in /etc/gai.conf.
> 
> The script I provide in my blog entry allows /etc/gai.conf to be used
> more as you would expect. The contents are picked up at boot time and
> delivered to the kernel using the "ip" program, and you can re-run the
> script whenever you need to manually update things.

Very nice work with what you've discovered and blogged about.  Still though, it sounds like there is room for improvement - especially since there could be systems with different prefix policies and you'll one to have a common set for one management domain.  I sure hope that draft to control prefix policies with DHCPv6 becomes a standard...

--Jim