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:   Wed, 11 Jan 2017 14:48:30 -0500
From:   "Jonathan T. Leighton" <jtleight@...l.edu>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org, edumazet@...gle.com,
        Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>
Subject: Re: TCP using IPv4-mapped IPv6 address as source



On 1/11/17 1:31 PM, Eric Dumazet wrote:
> On Wed, 2017-01-11 at 12:34 -0500, Jonathan T. Leighton wrote:
>> On 1/11/17 11:20 AM, Eric Dumazet wrote:
>>> On Thu, 2017-01-05 at 16:25 -0500, Jonathan T. Leighton wrote:
>>>> I've observed TCP using an IPv4-mapped IPv6 address as the source
>>>> address, which I believe contradicts
>>>> https://tools.ietf.org/html/rfc6890#page-14 (BCP 153). This occurs when
>>>> an IPv6 TCP socket, bound to a local IPv4-mapped IPv6 address, attempts
>>>> to connect to a remote IPv6 address. Presumable connect() should return
>>>> EAFNOSUPPORT in this case. Please advise me if this is not to
>>>> appropriate list to report this.
>>> Hi Jonathan
>>>
>>> I believe your concern makes sense.
>>> Do you have a patch to address this issue ?
>> Thanks for responding Eric. I have limited experience with kernel
>> patches. Nevertheless, unless there's someone with the experience and
>> time to jump on this, I'm interested in taking a crack at it. I think
>> the issue certainly warrants attention: instead of returning immediately
>> with EAFNOSUPPPORT, connect() retransmits its SYN 6 times, ultimately
>> returning ETIMEDOUT after 127 sec (1+2+4+...+64).
> I am not aware of an application trying to perform a bind() to an IPV4
> address before a connect() to an IPv6 destination.
>
> A kernel fix is certainly something that would detect application bugs
> in a more friendly way.

I would say that an IPv6 socket binds to an IPv4-mapped IPv6 address, 
but yes - using it to connect to an IPv6 address would be an application 
bug. It also think that having connect() spend 2 minutes sending packets 
containing an illegal source address is a bug. (And unfriendly!) I'll 
look into writing a patch for this, and let you know whether or not I 
think I'm up to it.

- Jon

> Thanks !
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ