tor/changes/ticket11243
Nick Mathewson a30594605e Treat unparseable (micro)descriptors and extrainfos as undownloadable
One pain point in evolving the Tor design and implementing has been
adding code that makes clients reject directory documents that they
previously would have accepted, if those descriptors actually exist.
When this happened, the clients would get the document, reject it,
and then decide to try downloading it again, ad infinitum.  This
problem becomes particularly obnoxious with authorities, since if
some authorities accept a descriptor that others don't, the ones
that don't accept it would go crazy trying to re-fetch it over and
over. (See for example ticket #9286.)

This patch tries to solve this problem by tracking, if a descriptor
isn't parseable, what its digest was, and whether it is invalid
because of some flaw that applies to the portion containing the
digest.  (This excludes RSA signature problems: RSA signatures
aren't included in the digest.  This means that a directory
authority can still put another directory authority into a loop by
mentioning a descriptor, and then serving that descriptor with an
invalid RSA signatures.  But that would also make the misbehaving
directory authority get DoSed by the server it's attacking, so it's
not much of an issue.)

We already have a mechanism to mark something undownloadable with
downloadstatus_mark_impossible(); we use that here for
microdescriptors, extrainfos, and router descriptors.

Unit tests to follow in another patch.

Closes ticket #11243.
2014-10-13 14:30:02 -04:00

8 lines
389 B
Plaintext

o Major features (downloading):
- Upon receiving a server descriptor, microdescriptor, extrainfo
document, or other object that is unparseable, if its digest
matches what we expected, then mark it as not to be downloaded
again. Previously, when we got a descriptor we didn't like, we
would keep trying to download it over and over. Closes ticket
11243.