MIT KDC only listening on lo

[Jeffrey Hutzelman]

On Thursday, September 23, 2004 01:57:50 +0200 Fredrik Tolf 
<fredrik at dolda2000.com> wrote:

> On Wed, 2004-09-22 at 19:43 -0400, Ken Raeburn wrote:
>> On Sep 22, 2004, at 18:50, Fredrik Tolf wrote:
>> > On Wed, 2004-09-22 at 22:37 +0000, Sam Hartman wrote:
>> >>>>>>> "Fredrik" == Fredrik Tolf <fredrik at dolda2000.com> writes:
>> >>
>> >>     Fredrik> Does anyone know if the KDC is configurable to just
>> >>     Fredrik> listen to 0.0.0.0, or will I have to take the time to
>> >>     Fredrik> patch it?
>> >>
>> >> You'll have to patch.
>>
>> Shouldn't be hard.  I think you need to dig up the code in the krb5
>> library (or include directory, or a copy in the KDC code? I forget
>> where 1.3 had it) that looks for IFF_LOOPBACK and disable it.
>
> It would be much better if it would listen to 0.0.0.0, since if I leave
> the network and then come back, I'm not always certain to be given the
> same IP address by the DHCP server. If I would get a new one, I'd have
> to restart the KDC to listen to it. Not a major deal, mayhap (especially
> considering I could restart the KDC from some network script), but
> slightly annoying, and pretty ugly.
>
> Do you think that's wrong?
>
>> Listening on 0.0.0.0 for UDP traffic may not work for hosts with
>> multiple addresses, since the client code may be checking that it got
>> its response back from the same address to which it sent the query.
>
> I'm sorry, but I'm not seeing the problem. When the reply is sent back,
> surely the kernel fills in the interface address in the source field of
> the IP header? Or am I missing something here?

Yes, you are.  In UDP there's no concept of "request", "reply", or 
"connection".  The kernel will indeed fill in the source address.  It will 
use the interface address of whatever outgoing interface is selected based 
on the best route to the destination address.

Unfortunately, the best route to the destination address may not be out the 
same interface whose address was on the original request.  In such a 
situation, the reply will go out with the _WRONG_ source address and the 
client will likely ignore it.

Consider the situation where the KDC for EXAMPLE.COM has two interfaces: 
le0 has address 192.168.1.1, and ec0 has address 10.42.1.1.  These are both 
on networks which are connected to the (hypothetical) Internet.  Now 
consider a client with address 192.168.1.2.  It sends a request to 
10.42.1.1, because that is one of the published addresses of the KDC for 
EXAMPLE.COM.  It's a perfectly reasonable request, and the KDC receives it 
via its ec0 interface.  The request has a source address of 192.168.1.2, so 
the KDC sends the reply to that.  Now, the best route to 192.168.1.2 is out 
le0, so the kernel tacks on le0's address (192.168.1.1) as the source 
address.  The client sees this packet from 192.168.1.1 and drops it on the 
floor.


For this reason, servers providing UDP-based services from multi-homed 
hosts generally need to maintain separate sockets for each interface, so 
they can determine to which address a request was sent and to arrange for 
that same address to be used as the source address on the reply.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA