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: <1422290961.2687.39.camel@redhat.com>
Date:	Mon, 26 Jan 2015 17:49:21 +0100
From:	Hannes Frederic Sowa <hannes@...hat.com>
To:	Brian Haley <brian.haley@...com>
Cc:	David Ahern <dsahern@...il.com>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional

On Fr, 2015-01-23 at 16:17 -0500, Brian Haley wrote:
> On 01/23/2015 01:23 PM, David Ahern wrote:
> 
> >>> Add a new sysctl to make this behavior optional. Setting defaults to flush
> >>> addresses to maintain backwards compatibility. When reset flushing is bypassed:
> >>>
> >>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> >>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> >>> [root@f20 ~]# ip addr show dev eth1
> >>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
> >>> default qlen 1000
> >>>      link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> >>>      inet6 2000:11:1:1::1/64 scope global tentative
> >>>         valid_lft forever preferred_lft forever
> >>> [root@f20 ~]#  ip link set dev eth1 up
> >>> [root@f20 ~]#  ip link set dev eth1 down
> >>> [root@f20 ~]# ip addr show dev eth1
> >>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
> >>> default qlen 1000
> >>>      link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> >>>      inet6 2000:11:1:1::1/64 scope global
> >>>         valid_lft forever preferred_lft forever
> >>>      inet6 fe80::4:11ff:fe22:3301/64 scope link
> >>>         valid_lft forever preferred_lft forever
> >>
> >> I think this was brought up in a previous thread on this, but don't you have to
> >> do DAD on these addresses once the interface comes back up?  Some other system
> >> could have come along, done DAD, succeeded, and is now using it.  Or does the
> >> use of this flag assume the user is Ok without doing DAD, and will deal with the
> >> fallout?
> > 
> > You have the same problem today, don't you? Current code allows an IPv6 address
> > to be configured on interface in the down state. The intent of this sysctl is to
> > allow that address to stay on an up-down cycle.
> 
> Yes, looks like ndisc_send_skb() never returns any lower-level error back up to
> the caller, so it's assumed the Neighbour Advertisement is always sent.
> Although the address will be marked "tentative" until IFF_UP is set.
> 
> > I don't have a strong IPv6 background so the first email thread and this RFC
> > patch are both asking first and foremost if there is any harm in this behavior.
> > None has been raised - so far. To maintain backwards compatibility this is a new
> > option which when reset allows the addresses to be retained (not flushed).
> 
> Seems as though you're in an RFC grey area then.  Personally, I'd do DAD, even
> though the possibility of a collision is always very small.  But that's just my
> opinion.

I agree. If the interface is in a state where it doesn't listen for
other hosts doing DAD, we must initiate DAD for that address during
bringing the interface up.

I am even not so sure if this is a grey area. Anyway, the current
behavior is not best and we should change that if the kernel does not do
DAD on addresses added during ifdown. Hopefully people don't use this
trick. :)

Bye,
Hannes


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ