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

[Stefan Winter <[e-mail]>]

Hi,

>> A "final result" here is one where all branches have been explored and
>> have all yielded hostnames. (the ultimate A and AAAA resolution comes in
>> a later step, as it's common for both the NAPTR and the fallback SRV
>> resolution; and it is a host prefence which protocol to try in the end.
> 
> Well, one is only supposed to explore the tree up to the point where
> one terminal NAPTR and its subsequent child lookup yields usable results,
> stop there and use those results, so that's not "all branches" really.
> 
> Then the implementation is expected to either continue exploring or restart
> exploring (depending on TTLs) whenever those results are deemed to no
> longer be usable.  So "final result" is probably not good nomenclature.  I'd
> suggest "terminal result" to tie it to the single parent NAPTR.
> 
> My question is really what to do when you have sets of either NAPTR RRs
> or SRV RRs all of which match your tag, but a few of which are obviously
> invalid (pointing to bogons, owned by "." or "", etc.).  The two good
> answers
> I see are "throw out the whole set and move on at the next higher level" and
> "ignore the bad ones and use the good ones" and I don't have much advice
> to offer as to which is best.

Okay... RFC3958 speaks of "Successive Resolution" and "terminal lookup".
I've changed the draft -07 to use that nomenclature.

Indeed, that same RFC suggests an (IMHO: odd) mixture of the descendence
of NAPTR -> SRV/A/AAAA lookups and the connection phase to a server;
it's in a way a greedy search which advises an implementation to proceed
to connection setup with the top-priority discovered host as soon as
it's discovered.

If that top-priority host turns out not to be acceptable or doesn't
respond, you are supposed to come back to discovery and try the
remaining options.

I don't like this approach; it is incompatible with the loop detection -
the querying server needs to find out whether it itself is in the set of
results; which requires the set to be complete.

I believe it also makes implementations harder; they've got to
temporarily break out of the algorithm, do their connection attempt, and
come back later if needed.

I prefer having a strict two-phase approach: do all DNS lookups for all
branches; then take the resulting set and try the servers in order of
preference.

That also nicely solves your backtracking question for bogus DNS
entries: RFC3958 declares these as "failure", which in its context means
return to backtracking immediately. Since my draft now doesn't need
backtracking, it merely needs to descend on all branches and ignore
those which are bogus. Either at least one branch yielded at least one
hostname, which means discovery worked and this set of hostnames is used
- or all entries were bogus, which means discovery did NOT work and we
need to back off for BACKOFF_TIME to wait for better days.

I've made a last-minute change to the draft to that effect. The step in
the algorithm now reads:

   9.   For the extracted NAPTRs, perform successive resolution as
        defined in [RFC3958], section 2.2.4, with the additional
        reservation that all records are to be immediately pursued
        through terminal lookup, i.e. have resulted in hostnames.
        Failure to achieve terminal lookup for individual records is
        non-fatal.

   10.  If the set of hostnames is empty, O-1 = { empty set }, O-2 =
        BACKOFF_TIME and terminate.

>> The three seconds are explained earlier in the draft (needs to be below
>> 5 due to RADIUS clients usually giving up after that amount of time).
>> Now that the value is configurable, implementations might tune that down
>> to smaller values if they see fit.
> 
> OK, I see the DNS_TIMEOUT, but I don't think we are quite yet on the same
> page here.  I agree that the 3 seconds value is correct for the amount
> of time
> after which a RADIUS request should be routed through the default (non-DDDS)
> path.  I don't think the amount of time that the DNS lookup may proceed
> (independent of the fate of the RADIUS request) needs to be related to this
> number, and I don't see a rationale presented for the default for THAT being
> 3 seconds, though I do see the need for it to be quite strictly limited
> for DoS
> prevention.
> 
> My instinct tells me that the longest you would want to keep scratching at
> DNS in the hopes of resolving the lookup before a failing client retries is
> near the typical client retry interval, but in most cases that will be
> overkill
> and a lower value based on actual "worst-but-not-pathological-case"
> real-world
> expected DNS performance would be better as a default value.

I've modified the Security Considerations text to make sure that it's
understood that DNS_TIMEOUT is one thing (for ops reasons), and the
waiting time for DNS to finish is another thing, implementation choice
and its duration is out of scope.

In any case, DNS_TIMOUT <= DoS-preventing waiting time. If you're only
willing to wait less time, then you effectively lower DNS_TIMEOUT
implicitly.

> I think this is fine.  Rate limiting is a very complex subject and the
> proper
> approach varies with details of the implementation, especially since
> you can easily thereby open the additional DoS vector of soaking the rate
> limit to deny service to legitimate requests.

Great.

>> I think min { X,Y } is the answer; if any one of the two has elapsed,
>> either a new NAPTR might show up -> worth re-executing the algorithm; or
>> it may not, but a new SRV might come up -> again worth re-executing.
> 
> This sounds like TRTTD.  With MIN_EFF_TTL mixed in I assume.

Correct; I'm using the Effective TTL ( ) function throughout the
algorithm, also for the negative TTL result from SOAs.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]