On Thursday, September 23, 2004 01:57:50 +0200 Fredrik Tolf <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

________________________________________________
Kerberos mailing list           [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to