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: <20160830195156.3ibvpbi4254wnput@alphalink.fr>
Date:   Tue, 30 Aug 2016 21:51:56 +0200
From:   Guillaume Nault <g.nault@...halink.fr>
To:     Eli Cooper <elicooper@....com>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Subject: Re: [PATCH v2] ipv6: Use inbound ifaddr as source addresses for
 ICMPv6 errors

On Mon, Aug 29, 2016 at 02:34:32AM +0800, Eli Cooper wrote:
> Hello,
> 
> 
> On 2016/8/29 1:18, Guillaume Nault wrote:
> > On Sun, Aug 28, 2016 at 11:34:06AM +0800, Eli Cooper wrote:
> >> According to RFC 1885 2.2(c), the source address of ICMPv6
> >> errors in response to forwarded packets should be set to the
> >> unicast address of the forwarding interface in order to be helpful
> >> in diagnosis.
> >>
> > FWIW, this behaviour has been deprecated ten years ago by RFC 4443:
> > "The address SHOULD be chosen according to the rules that would be used
> >  to select the source address for any other packet originated by the
> >  node, given the destination address of the packet."
> >
> > The door is left open for other address selection algorithms but, IMHO,
> > changing kernel's behaviour is better justified by real use cases
> > than by obsolete RFCs.
> 
> I agree, sorry for the obsoleted RFC. This is actually motivated by a
> real use case: Say a Linux box is acting as a router that forwards
> packets with policy routing from two local networks to two uplinks,
> respectively. An outside host from is performing traceroute to a host on
> one of the LAN. If the kernel's default route is via the other LAN's
> uplink, it will send ICMPv6 packets with the source address that has
> nothing to do with the network in question, yet the message probably
> will reach the outside host.
> 
> Here using the address of inbound or exiting interface as source address
> is evidently "a more informative choice." I surmise this is the reason
> why the comment reads "Force OUTPUT device used as source address" when
> dealing with hop limit exceeded packets in ip6_forward(), although not
> effectively so. The current behaviour not only confuses diagnosis, but
> also might be undesirable if the addresses of the networks are best kept
> secret from each other.
> 
That makes more sense indeed. Would be nice to have this use case in
the commit message rather than the blind reference to the obsolete RFC.

Regards,

Guillaume

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ