netdev - Re: IPV6 loopback bound socket succeeds connecting to remote host

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, 16 Dec 2010 12:18:05 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	shanwei@...fujitsu.com
Cc:	albertpretorius@...oo.co.uk, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org, pekkas@...core.fi, jmorris@...ei.org
Subject: Re: IPV6 loopback bound socket succeeds connecting to remote host

From: Shan Wei <shanwei@...fujitsu.com>
Date: Thu, 02 Dec 2010 16:41:39 +0800

> Albert Pretorius wrote, at 12/02/2010 03:45 PM:
>> Hi
>> 
>> --- On Wed, 1/12/10, Shan Wei <shanwei@...fujitsu.com> wrote:
>>> I think it make nonsense to translate data between loopback
>>> device and other e.g. eth0 device in same machine.
>> 
>> I agree, RFC4291 makes it clear for IPV6 that no interface should accept traffic from loopback, I should not have tried to make it behave like IPV4.
>> I can not find an equivalent statement for IPV4 though, all I could find is this from RFC3330:
>> 
>>    127.0.0.0/8 - This block is assigned for use as the Internet host
>>    loopback address.  A datagram sent by a higher level protocol to an
>>    address anywhere within this block should loop back inside the host.
>>    This is ordinarily implemented using only 127.0.0.1/32 for loopback,
>>    but no addresses within this block should ever appear on any network
>>    anywhere [RFC1700, page 5].
>> 
>> Do you perhaps know?
> 
> There are no same statement for IPv4 loopback address. I have checked RFC1122, RFC1700 and RFC5753 .		

Shan, you really need to handle this in the ipv6 routing code.

Your approach will only modify socket based route handling, it will
not handle the ipv6 forwarding case which as per the quoted RFC
sections must be handled too.
--
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