Re: Why krb5kdc and kadmind sets up ports for listening differently ?

Hi Ken & Kerberos folks,
Its been proved that using wild-card for UDP doesn't suits the way Kerberos
works.
On the other hand TCP works fine using wild-card and fits into the
requirements of Kerberos. Seeing that I am having a question.

Why KDC by default listens on UDP ? Why can't by default it listens just on
TCP or both on TCP & UDP ? Any specific reasons behind that ?
Awaiting reply.

- Sachin.

On Fri, Feb 22, 2008 at 1:35 PM, Sachin Punadikar <
punadikar.sachin@xxxxxxxxx> wrote:

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@xxxxxxxxxxx> 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



.