netdev - Re: [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation

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: <1320482392.98040.YahooMailNeo@web126003.mail.ne1.yahoo.com>
Date:	Sat, 5 Nov 2011 01:39:52 -0700 (PDT)
From:	François-Xavier Le Bail <fx.lebail@...oo.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation

>From: Eric Dumazet <eric.dumazet@...il.com>
>To: François-Xavier Le Bail <fx.lebail@...oo.com>
>Sent: Friday, November 4, 2011 5:24 PM
>Subject: Re: [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation
>
>Le vendredi 04 novembre 2011 à 07:46 -0700, François-Xavier Le Bail a
>écrit :
>> I do some tests on a Linux 3.0 kernel with IPv6 forwarding mode enabled.
>> 
>> When I ping (ICMPv6 echo request) on one of its Subnet-Router anycast addresses
>> (SRAA, http://tools.ietf.org/html/rfc4291#section-2.6.1),
>> the Linux kernel reply with an unicast source address, not the anycast one.
>> 
>> When I send an IPv6 UDP packet to a server on Linux on one of its SRAA,
>> the Linux kernel build a reply with an unicast source address, not the anycast one.


Thanks for your answer.

>Nothing in the kernel builds a reply to an UDP packet.

You are right. I meant that in some cases the kernel selects the source address
of the reply.

>I would say the user application is responsible to build an answer, and
>chose appropriate source address.


OK.


>If your application uses a ANY_ADDR bind, then it must appropriate
>action so that a good source address is used in answers.
>
>In case of IPv6 socket, I advise you take a look at IPV6_PKTINFO /
>IPV6_RECVPKTINFO options.


I will study and test these options for my application server.

>> The RFC 4942 states (http://tools.ietf.org/html/rfc4942#section-2.1.6) :
>> 2.1.6. Anycast Traffic Identification and Security
>> [. . .]
>>    To avoid exposing knowledge about the internal structure of the
>>    network, it is recommended that anycast servers now take advantage of
>>    the ability to return responses with the anycast address as the
>>    source address if possible.
>> 
>> Also, If the source address of reply differs from destination address of the request, many applications are broken.
>> Please let me know your feedback.
>> 
>
>'anycast servers' are a combination of kernel and userland parts.


Agreed, but remain the case of ICMPv6 echo request/reply, which I think is in kernel.

Francois-Xavier
--
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