Why krb5kdc and kadmind sets up ports for listening differently ?

[Sachin Punadikar]

Ken,

Thanks a lot for the information.
I tested KDC, enabeling it to use a wild-card and UDP only (I removed call
to get_interfaces). I did get failure when client (kinit) contacted KDC
using the alias. After checking the log file of KDC, it showed that it is
replying back, but client is not accepting it because the reply is coming
from real ip and not the alias.
When used the real ip for contacting KDC, then it worked fine.
This proves the things.

- Sachin.

On Fri, Feb 22, 2008 at 8:51 AM, Danny Mayer <mayer at ntp.isc.org> wrote:

> Ken Raeburn wrote:
> > On Feb 19, 2008, at 02:17, Sachin Punadikar wrote:
> >> While doing code walkthrough of krb5kdc and kadmind programs,
> >> I noticed a difference between these two in the way it sets up the
> >> ports for listening.
> >> krb5kdc uses ioctl calls to get the interfaces list and then on each
> >> interface/ip-address its sets up the port for listening.
> >> While in case of kadmind it uses wildcard to set up the port for
> >> listening.
> >>
> >> Any specific reason for having different approaches while setting
> >> up ports?
> >
> > The UDP service offered by the KDC needs to respond from the same IP
> > address that the client used to reach it.  That's not possible with a
> > wildcard-address listener unless your system has support for
> > IP_PKTINFO or IPV6_PKTINFO, which is now supported in our code as
> > well.  The TCP listener does use a wildcard address.
> >
> > In kadmind, we're only using TCP, so it can just use the wildcard.
> >
>
> We do the same thing in both NTP and BIND since it's important to reply
> using the same IP address as the query was sent to. Anything else is
> unexpected by the party making the query. This means creating separate
> sockets for each supported IP address/port. You cannot guarantee the
> same result using a wildcard unless you are able to capture that
> information using IP_PKTINFO or IPV6_PKTINFO, as Ken said. We end up
> interating through the interfaces to do it right.
>
> TCP doesn't have the same problem since you need to establish a
> connection and then you have the right address in the response packets.
>
> Danny
>