[19337] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: krb5 UDP daemons and IP pktinfo

daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Jan 5 17:22:21 2016

Message-ID: <1452032530.3830.47.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Date: Tue, 05 Jan 2016 17:22:10 -0500
In-Reply-To: <x7dd1tfd6yc.fsf@equal-rites.mit.edu>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On Tue, 2016-01-05 at 16:58 -0500, Greg Hudson wrote:
> MIT krb5 contains two UDP daemons, krb5kdc and kadmind (for password
> changes).  For UDP daemons, it is sometimes important to send replies
> from the same address as the requests were sent to, or the replies may
> be discarded by firewalls or NAT devices.  The BSD sockets interface
> does not provide this functionality if you bind the server socket to the
> wildcard address.  For IPv6, there is a standardized and widely
> implemented extension (IPV6_PKTINFO) which provides the needed
> functionality.  For IPv4, the situation is more fragmented (see below).
> As a result, we have some complicated code in lib/apputils/net-server.c
> which does the following for each of IPv4 and IPv6:
> 
> * If pktinfo suport is present, we bind to the wildcard address and set
>   the socket to use pktinfo.
> 
> * Otherwise, we loop over the local interfaces and bind to each one.  We
>   also bind to the routing socket.  When a message is received on the
>   routing socket indicating that local interfaces have changed, we close
>   all sockets (including active TCP connections) and rebind listener
>   sockets from scratch.
> 
> In 2010 I asked for help doing a platform survey, and found that while
> Linux and Solaris 11 implement an IPv4 variant of pktinfo (IP_PKTINFO),
> other platforms do not (NetBSD added it in 2013).  Until yesterday, my
> operating assumption was that we were stuck with the complex code for
> the forseeable future.  Yesterday, I discovered that some operating
> systems implement the same functionality in a different way
> (IP_RECVDSTADDR).  If we handle both variants, then we can safely bind
> to the IPv4 wildcard address on Linux, Solaris, all of the BSDs, and OS
> X.
> 
> So, I think it might be reasonable to simplify the net-server.c code at
> the expense of some degradation on the rare platforms which don't
> implement either variant of IPv4 pktinfo.  My favored form of
> degradation is that we always bind to the wildcard address, and if the
> platform doesn't have IPv4 pktinfo support, we just let sendto() pick
> the source address of the reply.  For those platforms, our UDP daemons
> will continue to work on single-homed machines, but might not behave
> properly on multi-homed machine depending on the routing configuration.
> 
> Do other people agree that this is reasonable?

Sounds perfectly reasonable to me.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post