netdev - Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support

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: <e390f13d-f45b-9566-63c3-64ed1292da53@oracle.com>
Date:   Tue, 26 Jun 2018 21:02:43 +0800
From:   Ka-Cheong Poon <ka-cheong.poon@...cle.com>
To:     Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:     netdev@...r.kernel.org, santosh.shilimkar@...cle.com,
        davem@...emloft.net, rds-devel@....oracle.com
Subject: Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support

On 06/26/2018 06:16 PM, Sowmini Varadhan wrote:
> On (06/26/18 13:30), Ka-Cheong Poon wrote:
>>
>> My answer to this is that if a socket is not bound to a link
>> local address (meaning it is bound to a non-link local address)
>> and it is used to send to a link local peer, I think it should
>> fail.
> 
> Hmm, I'm not sure I agree. I dont think this is forbidden
> by RFC 6724 - yes, such a packet cannot be forwarded, but
> if everything is on  the same link, and the dest only has
> a link-local, you should not need to (create and) bind
> another socket to a link-local to talk to this destination..


In this case, RFC 6724 prefers link local address as source.
While using non-link local address (say ULA) is not forbidden,
doing this can easily cause inter-operability issues (does the
app really know that the non-link local source and the link
local destination addresses are really on the same link?).  I
think it is prudent to disallow this in RDS unless there is a
very clear and important reason to do so.  BTW, if it is really
needed, it can be added in future.


>>   This is consistent with the scope_id check I mentioned in
>> the previous mail.  If the socket is not bound to a link local
>> address, the bound_scope_id is 0.  So if the socket is used to
>> send to a link local address (which has a non-zero scope_id), the
>> check will catch it and fail the call.  A new conn should not
>> be created in this case.
> 


-- 
K. Poon
ka-cheong.poon@...cle.com