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

[Stefan Winter <[e-mail]>]

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 <[e-mail]>
To: Stefan Winter <[e-mail]>



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