netdev - Re: [PATCH net-next] IPv6: enable TCP to use an anycast address

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: <20140113011146.GG6586@order.stressinduktion.org>
Date:	Mon, 13 Jan 2014 02:11:46 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	François-Xavier Le Bail <fx.lebail@...oo.com>
Cc:	Alexey Kuznetsov <kuznet@....inr.ac.ru>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	James Morris <jmorris@...ei.org>,
	Hideaki Yoshifuji <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH net-next] IPv6: enable TCP to use an anycast address

Hi!

On Sun, Jan 12, 2014 at 06:53:47AM -0800, François-Xavier Le Bail wrote:
> On Sat, 1/11/14, Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
> 
> > On Sat, Jan 11, 2014 at 05:38:27PM +0400, Alexey Kuznetsov wrote:
> > > On Sat, Jan 11, 2014 at 5:06 PM, François-Xavier Le Bail
> > > <fx.lebail@...oo.com> wrote:
> > > > Many DNS root-servers use TCP with anycast (IPv4 and IPV6).
> > > 
> > > Actually, I was alerted by reset processing in your patch, it cannot be right.
> > > 
> > > Do not you think this must not be enabled for common use? At least
> > > some separate sysctl disabled by default.
> 
> > The idea I had, was, that if a socket does knowingly bind to an anycast
> > address, it is allowed to do so and process queries on it with both TCP and
> > UDP. I don't think we need a sysctl for that? Anycast addresses are either
> > pre-defined (e.g. the subnet router anycast address) or specified by a flag
> > when the administrator adds one. Currently one can only add anycast addresses
> > either by forwarding and gets the per-subnet anycast address or with a
> > setsockopt IPV6_JOIN_ANYCAST.
> 
> > So the problem is what should be allowed when the socket listens on an any
> > address? Maybe this should be protected by a sysctl?
> 
> TCP case:
> With my two patches (the one for bind and this one for tcp), when a
> SOCK_STREAM socket listen to in6addr_any, the server is able to 
> send TCP reply with unicast or anycast source address, according
> to the destination address used by the client.
> 
> dest request unicast => src reply unicast (current behavior)
> dest resquet anycast => src reply anycast (new)
> 
> So, I don't think there is a need for a sysctl.

I am still thinking about the RST-case and am a bit unsure here. But I
currently don't see any problems.

> UDP case:
> By default (no socket option), the server program don't know the
> destination address of the request. The ipv6_dev_get_saddr() is 
> used for choosing the unicast source address of the reply.
> 
> I am not sure a change is needed here.

If the socket did bind to anycast address, we may well send packets from
anycast source without switching a sysctl IMHO.

If not bound we need to keep current behaviour, yes. As DNS-Servers
normally do accept a list of addresses where to bind to, I find this
acceptable. RFC6724 additionally now allowes the selection of anycast
as source address, so we may think about this and maybe integrate this
with ip addrlabel and such).

We also need to check the implications to icmp here (error reporting if
an UDP packets is sent to an anycast address). Also we have to check for
icmps generated because of forwarding errors and their source selection.

> When using IPV6_RECVPKTINFO, a server is able to know
> the destination address of the request and can use it as source
> address for the reply.
> To enable anycast for this (don't get EINVAL), there is need for
> a patch like the one I posted ("IPv6: add option to use anycast
> addresses as source addresses for datagrams").
> I am working on a v2.

Ack.

> With the appropriate change:
> dest request unicast => src reply unicast (current behavior)
> dest resquet anycast => src reply anycast (new)
> 
> I don't think, there either, there is a need for a sysctl.

I agree here.

Greetings,

  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