Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery

[Alan DeKok <[e-mail]>]

Stefan Winter wrote:
> That's another approach, which would also work. There's a very small
> probability that two unrelated packets happen to get the same packet-id;
> that kind of indeterminism makes me a bit nervous.

  There's no good solution for global uniqueness.  It can be mitigated
via a 128-bit ID.  That means the probability of two IDs being the same
is one in 2^64, which is rare enough to not really worry about.

> That doesn't really help: the forward and reverse IP checks work on the
> A/AAAA pair that is the "leaf" of the discovery process. Third parties
> adding a NAPTR where they should not will not be detected. If the end
> server is actually offering a dynamic discovery endpoint, then it will
> be properly configured for its legimiate customers. Having other people
> send non-legitimate customers to the same destination as well will not
> be detectable with an IP address check.

  I'm not sure.  Maybe I'm missing something.  If a proxy is about to
send radsec traffic for realm A to IP address B, can't it do a DNS
lookup on IP address B to see if realm A is listed?

> For a next rev of dynamicdiscovery, I've added the following paragraph
> for Security Considerations in my working copy:
> 
>    With Dynamic Discovery being enabled for a RADIUS Server, and
>    depending on the deployment scenario, the server may need to open up
>    its target IP address and port for the entire internet, because
>    arbitrary clients may discover it as a target for their
>    authentication requests.  If such clients are not part of the roaming
>    consortium, the RADIUS/TLS connection setup phase will fail (which is
>    intended) but the computational cost for the connection attempt is
>    significant.  With the port for a TLS-based service open, the RADIUS
>    server shares all the typical attack vectors for services based on
>    TLS (such as HTTPS, SMTPS, ...).  Deployments of RADIUS/TLS with
>    Dynamic Discovery should consider these attack vectors and take
>    appropriate counter-measures (e.g. blacklisting known-bad IPs on a
>    firewall, rate-limiting new connection attempts, etc.).
> 
> Is that okay for you?

  Yes.

  Alan DeKok.