[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Dynamic discovery: applicability questions



> Of course, what was I thinking? Setting up a CA, issuing client and server
> certs and configuring secure DNS is _so_ much simpler than laboriously
> typing an IP address. This simplicity must explain the amazing popularity
> (indeed, true ubiquity) of the PKI today.

One of the concerns that Pasi Eronen raised in Issue 303 was credential support.

I'd suggest that this issue needs to be thought through both with respect to
proxies/servers as well as for NASes.

While my understanding is that certificates have been used in RADSEC
deployments,  deploying certificates on NASes for use with RADIUS/DTLS
could be considerably more difficult. 

This raises the question of what TLS ciphersuites should be recommended/required
(e.g. PSK for DTLS).

Also, typically NASes are configured with the address of the proxy or server, and
therefore don't need to dynamically discover it.  The situation is a bit like default
route configuration with IPv4.

So I'm wondering whether this is primarily a concern for proxies running RADSEC,
since those seem the most likely to have a certificate as well as to be in need of
dynamic discovery capability.

With respect to standardization of dynamic discovery, experience with SIP (e.g. RFC 3263)
has been that supporting multiple transports can be the source of interoperability problems,
and that if not carefully specified, dynamic DNS discovery can actually make things worse.

For example, I'd suggest that a RADIUS server should probably not use dynamic discovery
to decide how to answer an incoming Request.  This could result in an incoming RADSEC
packet being answered with a RADIUS over DTLS packet.  The logical thing to do is for a
responder (either a RADIUS server or a DAS) to respond with the same transport that was
used in the Request.

I'm also not sure whether a DAC should use dynamic discovery to decide how to speak
to a DAS.  In this situation, there is presumably information available on the transport used
by the RADIUS client in the Access-Request.  Wouldn't it make more sense for the DAC
to use that same transport in speaking to the DAS?