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

From: Stefan Winter <[email-masked]>
Date: Thu, 04 Jul 2013 14:43:17 +0200

Follow-up from the implementer...

-------- Original Message --------
Subject: RE: [radext] Fwd: RE: Mail reguarding
draft-ietf-radext-dynamic-discovery
Date: Wed, 3 Jul 2013 16:16:21 +0000
From: Brian Julin <[email-masked]>
To: Stefan Winter <[email-masked]>

Stefan,

Thanks again for your responses.  Most of the issues seem to be addressed
or will be address in the next draft, so I'll wait for that and offer more
comments then (and in the meantime adapt the code I'm working on.)

A couple things still seem worth wrangling trough:

> 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.

> > Some of these vectors will exist whether or not the implementation stops
> at
> > three seconds.  Also the 3 second value is for the benefit of RADIUS
> > protocol
> > fallback needs and should probably not be conflated with a secure value for
> > abating DoS attacks.  Implementations could use an arbitrary value here
> > that is
> > more than 3 seconds but still reasonably finite.  What administrators
> > will want
> > instinctively is for the resolution to continue for their usual client
> > retry interval,
> > and continue thereafter if refreshed by a retry.
> 
> I've now moved that integer to an explicit configuration variable with a
> (sane?) default of 3 seconds.

[... snipped and rearranged the order a bit here]

> > If discussions have come up with an advised default value that is
> > coincidentally
> > also 3 seconds, distinguish this value from the limit on individual
> > queries and
> > present solid rationale as to why 10 to 30 seconds (typical for retries)
> > is too
> > long whereas 3 seconds is not.
> 
> 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.

[ snip ]

> That is some form of rate-limiting and has also been suggested by others
> on the list. I'm sympathetic with adding text towards rate-limiting; I
> am against being prescrptive towards implementations how they should do
> that. I'm adding this sentence to the corresponding section in Security
> Considerations:
> 
> "Note that even a timeout of three seconds may wreak havoc
>    when being attacked large-scale; implementations are advised to
>    consider rate-limiting either their amount of new executions of the
>    dynamic discovery algorithm as a whole, or the amount of intermediate
>    responses to track, or at least the number of pending DNS queries."

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.

[snip]

> Imagine a realm without dynamic discovery targets, neither NAPTR nor SRV
> labels.
> 
> The NAPTR query will yield a negative TTL X; the subsequent SRV fallback
> query will yield its own negative TTL Y.
> 
> How long should the caller of the algorithm be told to back off?
> 
> 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.

--
Brian S. Julin

---

From: Stefan Winter <[email-masked]>
Date: Thu, 04 Jul 2013 15:00:55 +0200

Hi,

> 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.

> 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.

> limit to deny service to legitimate requests.

Great.

> 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: +352 424409 1
Fax: +352 422473