Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

[Nathaniel McCallum <[e-mail]>]

On Tue, 2016-05-17 at 20:36 -0400, Jeffrey Altman wrote:
> On 5/17/2016 5:26 PM, Nathaniel McCallum wrote:
> > 
> > I've described a reason why a URI record lookup is requied for MS-
> > KKDCP. However, I've also described a system which presents a 50%
> > reduction in DNS lookups. I don't see any reason to neglect this
> > second
> > feature.
> 
> And when the DNS URI record is not published or cannot be queried the
> Kerberos library will have a 50% increase in the number of DNS
> lookups.
> Not only does the library have to query for DNS URI but it still must
> query for the DNS SRV records.

This is, indeed, the trade-off to a longer-term improvement. As I said
before, the property that makes this trade-off acceptable (IMHO) is
that the DNS administrator can solve this problem. This performance
trade-off creates an incentive for administrators to move to the new
system.

I'm very open to alternative designs. But we've been having this
conversation for more than a year now and, while lots of alternatives
have been proposed, all of them were abandoned by their proposers after
due consideration.

Here is a basic summary of the ideas proposed (please remind me if I've missed any):

1. A new, Kerberos-specific RR type.
2. (Ab)using TXT; same semantics as the current draft.
3. (Ab)using TXT; same semantics as RFC4120 - KKDCP only.
4. Using SRV with a default path.


#1 was dismissed as generally having the effect of ghettoizing the discovery mechanism. Servers wouldn't implement it. Neither would administrative interfaces. It also has all the same drawbacks as the current draft.

#2 is the exact same proposal as the existing draft, just using TXT records. Its main advantage over the current draft is that we don't need to depend on the URI record type. However, using the TXT record like this is controversial (to say the least).

#3 is the simplist solution: just define a TXT record for KKDCP only. This record would work in parallel to the existing SRV records and would only indicate the location of the KKDCP proxy. The downside is that this adds an additional query just for KKDCP. Future tunnels may add more queries. Also, it doesn't allow for weights/priorities between protocols.

#4 proposes to define an SRV record for KKDCP. This would carry the understanding that the default path (/KdcProxy) would always be used. This is basically a hack and is extremely inflexible. It would mean, in many cases, that the KKDCP proxy couldn't be integrated directly into existing infrastructure.

Notice that in all of the options we require an additional DNS query.
This is unavoidable.

#3 and #4 do not provide any opportunity for speedup. This means that
KKDCP users will have to wait for two DNS timeouts in order to get
connectivity. I find this property unacceptable. #1 and #2 have the
potential for speedups, with exactly the same semantics as the current
draft. But they each have significant drawbacks as well.

The current draft seems to me the best balance of all the options.

1. It uses a standard RR type. While the use of URI may be somewhat
controversial, it seems to me less problematic than either of the
alternatives (a custom RR type or TXT).

2. It does add an additional DNS query; but this can be avoided if DNS
configuration is updated. This is the best case scenario considering an
extra query will be required in all options.

3. It provides the ability to use weights/priorities between protocols.

> I will also point out that a large number of the DNS hosting
> providers
> do not support URI records and many of the DNS proxy servers do not
> support them either.   As a result there is no ability for DNS URI
> records to be published and the queries are will be blocked.

On the MIT krb5 call this week, I argued this very point against #1
(above). What I argued is that it will be easier to get hosting
providers to add support for URI than for some Kerberos-specific type.
If hosting providers were the only consideration, then TXT would be a
no-brainer here. However, there are also standardization
considerations. If the general consensus is that standardizing on TXT
won't present any difficulty, I would be more than happy to switch to
this option.

If you have any alternative, more creative, solutions, I'm all ears.
If, after this explanation, you agree that our solution is the best
balance of all the concerns, I am also open to suggestions for
improvements in the implementation.

It is my hope that we can agree upon the contours of the problem and
devise a solution that is acceptable to everyone.

Nathaniel