netdev - Re: Why does a connect to IPv6 LLA address fail ?

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]

Date:	Thu, 8 Nov 2007 19:32:22 +0100
From:	Karsten Keil <kkeil@...e.de>
To:	Vlad Yasevich <vladislav.yasevich@...com>
Cc:	Andreas Gruenbacher <agruen@...e.de>, Jiri Bohac <jbohac@...e.cz>,
	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org, kkeil@...e.de
Subject: Re: Why does a connect to IPv6 LLA address fail ?

On Thu, Nov 08, 2007 at 01:15:52PM -0500, Vlad Yasevich wrote:
> Andreas Gruenbacher wrote:
> > On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> >> The reason is that 2 different hosts may have the same link-local
> >> address as long as they are on different links.  If the sender is
> >> connected to both links then it may send the packet to the wrong
> >> destination.
> > 
> > Good point.
> > 
> > What's confusing is that connect(2) fails even if the host itself has the 
> > specified address. This isn't necessary.
> 
> Yes and no.  Since linux doesn't have the concept of default zone, we have
> to fail, because from the perspective of the kernel, the address was not
> fully specified.  OTOH, since this is our address, we 'could' have all
> the info.
> 

> The problem is that this verification happens before we hit the routing logic.
> It's an explicit check the if the sin6_scope_id is not set and we are not bound
> to an interface, it's an error.
> 

OK I run into this issue while running the TAHI testsuite. The test is as
follows:

  Check 03:
    DNS Address: fec0::9
    Candidate Source Addresses: fec0::1(SS) or LLA(LS)
    Destination Address List: 3fff::2(GS) or fe80::2(LS)
    Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1)

    Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) <> Scope(fec0::1), then prefer fe80::2

the nameserver send following answer for the query:

| | | | DNS_Question                    (length:21)
| | | | | DNS_QuestionEntry               (length:21)
| | | | | | Name                             = server.tahi.org.
| | | | | | Type                             = 28 (AAAA)
| | | | | | Class                            = 1
| | | | DNS_Answer                      (length:86)
| | | | | DNS_RR_AAAA                     (length:43)
| | | | | | Name                             = server.tahi.org.
| | | | | | Type                             = 28
| | | | | | Class                            = 1
| | | | | | TTL                              = 0
| | | | | | Length                           = 16
| | | | | | Address                          = 3fff::2
| | | | | DNS_RR_AAAA                     (length:43)
| | | | | | Name                             = server.tahi.org.
| | | | | | Type                             = 28
| | | | | | Class                            = 1
| | | | | | TTL                              = 0
| | | | | | Length                           = 16
| | | | | | Address                          = fe80::2



So how we should handle this issue, claim that the test is wrong, the test
should not use LLA for this ?

-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html