Colm MacCárthaigh wrote: > > On Thu, Feb 6, 2014 at 2:37 PM, Paul Vixie <[email protected] > <mailto:[email protected]>> wrote: > >> For example, if the authoritative provider www.example.com >> <http://www.example.com> were to implement RRL as you describe, >> then an attacker could spoof traffic purporting to be from Google >> Public DNS, OpenDNS, Comcast ... etc, and cause www.example.com >> <http://www.example.com> to be un-resolvable by users of those >> resolvers. > > no. it just does not work that way. > > > O.k., so say I spoof 10M UDP queries per second and 10M TCP SYNs per > second purporting to be from OpenDNS's IP address. Does RRL a) Let > the queries and SYNs go answered. Or b) Rate limit the responses? > > If it's (a) RRL doesn't prevent the reflection. If it's (b) then you > complete a denial of service attack against the OpenDNS users. > > Which is it? or what's option (c)?
first, i think we need smaller numbers, since at those volumes, opendns's pipes are full, and nobody would get any answers to any questions. so let's pick some number of requests and SYNs per second that is enough to use all the head room opendns had, but without affecting response flows to queries not related to your attack. second, RRL does not see SYNs. the kernel probably has SYN flood protection, which like a stateful firewall might penalize a host or netblock's real SYNs, but that has nothing to do with RRL's logic. furthermore, RRL is not invoked for TCP-received queries. whatever TCP sessions are able to start up are presumed to not have a forged other-end. what you really want here is to use non-spoofed TCP SYN so that you can camp onto all available connection control blocks. if opendns follows RFC 1035, it won't close TCP sessions until something like two minutes of idle time. you'd so, third, let's look squarely at "large enough UDP flow to activate RRL". when RRL is active for a flow, it means the server is controlling its responses to UDP questions which are from a certain netblock and which produce a given response. by "control" i mean "don't just answer, think about it first, consider your alternatives". one alternative is to drop the question unanswered. another alternative is to answer with a truncated UDP having TC=1. by default, netblocks are /24's and every third prospective response is sent as a TC=1, and we will of course send normal answers from time to time also. RRL's goal is attenuation, not silence. in your example, the forger is using a netblock that contains opendns's upstream address, and it is soliciting responses similar to the ones that opendns is trying to fetch. opendns only fetches from authorities when it has a cache miss, so you have to find something to spoof that opendns does not yet have in cache (or which has a very low TTL). in that steady state situation, opendns's legitimate queries whose response matches an RRL flow are mixed with an avalanche of forged questions soliciting the same answer. opendns will retry three times over ten to 90 seconds. if opendns ever gets an answer, it will fill its cache and stop asking that question. the possibility of opendns receiving a TC=1 and retrying with TCP, or receiving one of our periodic normal answers, and either way filling its cache is high, on the order of unity. of course, opendns might ask other authorities in between retries to any one authority, so you'll need to spoof all of the potential authorities who could help with the terminal cache-fill operation that ends the race. my advice is, don't take my word for it. build a VM farm inside your laptop, set up a test environment, perform the experiment, and show us all the recipe that results in maximum retries for a DNS stub. show the effort required to deliberate create a service-affecting outage using RRL. i think you'll find this an unsatisfying exercise but i am ready to study your results. so, (c). vixie
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
