On 1/22/20 09:52, Tommy Pauly wrote:
There should certainly be a minimum time between fetches, which we can specify
here.
Beyond this, I think there's actually a relatively straightforward solution
that's latent in the text but needs to be called out in the security
considerations.
The privacy considerations note that the Additional Information server should
limit access to valid clients (and if it checks the client public address, this
can prevent the NAT66 trick):
Network operators SHOULD restrict access to PvD Additional
Information to only expose it to hosts that are connected to the local
network... [this] can be implemented by
whitelisting access from the addresses and prefixes that the router provides
for the PvD, which will match the prefixes contained in the PvD Additional
Information.
To be clear, I'm far less concerned about DDoS attacks on PvD Additional
Information servers [1] than I am about attacks on general-purpose web
servers.
In addition, the client is told to "abandon" requests and consider that a PvD
has no additional info if it receives HTTP 400 errors:
If the HTTP status of the answer is greater than or equal to 400
the host MUST abandon and consider that there is no additional PvD
information.
My thought is to specify that the server rejects clients with a 400-level if
they are not indeed from its own PvD; and similarly to specify that clients
don't retry and effectively blacklist the PvD Additional Info in this case, or
if they don't get valid JSON back.
Durable blocklisting (e.g., blocks that survive reboots) of specific PvD
IDs on 400-class errors certainly helps in some cases (non-PvD servers
will likely return 401, 403, or 410 for PvD requests), but it falls down
in the fairly common case of web servers pointed to by wildcard DNS
records. For example, an attacker could flood github.io by first sending
out a PvD id of "1.github.io" and then, milliseconds later, sending out
a PvD id of "2.github.io", and so on, indefinitely.
So, a few additional thoughts to throw into the hopper -- all of which
have some drawbacks -- would be to consider:
* Instead of blocklisting individual PvD IDs, blocklist all hosts
under a corresponding eTLD [2]
* If a PvD Additional Information server returns a 400-class response,
persistently block the sender of the RA (I don't know offhand how
one might do this in a way that can't be evaded, though. Source IP
address clearly won't work, and source MAC is probably too easy to
change as well)
* Add a mechanism to the RA interaction that requires at least as much
work on the attacker's part (both in terms of network usage and
computational complexity) as the HTTPS connections themselves, thus
eliminating the amplification (think challenge/response
proof-of-work approaches here).
* Add a large, global (i.e., not per-PvD ID) throttle (on the order of
minutes or hours) between acting on received PvD RAs
* Require clients to check in DNS (or some other highly scalable
database) that the PvD Additional Information server has opted in to
being a PvD Additional Information server. As an example of one
possible way to do this: for the PvD ID foo.example.com, clients
would have to first check for the presence of a DNS TXT record
_pvd.foo.example.com. (See RFC 8552 if you choose to do something
like this).
/a
____
[1] The optional nature of the information they serve makes them
non-critical
[2] I know you know what this is, but for the benefit of others, see
https://en.wikipedia.org/wiki/Public_Suffix_List
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
