netdev - Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080302165453.GP32279@verkkotelakka.net>
Date:	Sun, 2 Mar 2008 18:54:53 +0200
From:	Juha-Matti Tapio <jmtapio@...kkotelakka.net>
To:	"YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@...ux-ipv6.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID
	addresses

On Sun, Mar 02, 2008 at 09:39:02PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <20080221100842.GA24905@...kkotelakka.net> (at Thu, 21 Feb 2008 12:08:42 +0200), Juha-Matti Tapio <jmtapio@...kkotelakka.net> says:
> > Skip the prefix length matching in source address selection for
> > orchid -> non-orchid addresses.
> > 
> > Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
> > 2001:10::/28) are currenty not globally reachable. Without this
> > check a host with an ORCHID address can end up preferring those over
> > regular addresses when talking to other regular hosts in the 2001::/16
> > range thus breaking non-orchid connections.
> > 
> > Signed-off-by: Juha-Matti Tapio <jmtapio@...kkotelakka.net>
> 
> Is this really required?
> I believe address labels (rule 6) should work, no?

The corner case that I run into was like this (using HIPL):

$ ip -6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
    inet6 2002:4fab:e944:1100::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2c0:4fff:fe17:ecd9/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qlen 100
    inet6 fe80::2/64 scope link
       valid_lft forever preferred_lft forever
8: dummy0: <BROADCAST,NOARP,UP,10000> mtu 1500
    inet6 2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52/28 scope global
       valid_lft forever preferred_lft forever
[...]

$ ip -6 route
2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52 dev dummy0  metric 1024  expires 8567991sec mtu 1500 advmss 1440 hoplimit 4294967295
[...]
2002:4fab:e944:1100::/64 dev eth0  metric 256  expires 8211503sec mtu 1500 advmss 1440 hoplimit 4294967295
[...]
default via fe80::1 dev tun0  metric 512  expires 8211512sec mtu 1500 advmss 1440 hoplimit 4294967295
[...]

In this case if I try to connect to www.ripe.net alias
2001:610:240:11::c100:1319, there is no local source address that
matches the destination's label and the outgoing interface does not
have any public addresses. Therefore the 8th rule applies and the HIT
(2001:...) wins and the destination can not understand the source
address.

I'm not particularly happy with the above mentioned second patch, but
I could not come up with a more elegant fix.


-- 
Tmi Juha-Matti Tapio    Puh/Tel. +358-50-5419230
Y-tunnus 1911527-0      Fax      +358-9-34756631

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)