As I understand the described attack, we are concerned with a case in which:
- A rogue RA is sent by the attacker to one or more clients - The clients are being used to amplify by sending HTTP requests to a victim server - The HTTP server receives a high load of attack requests from unwilling clients The mitigations fall into two general categories: (1) ensuring that clients can be less easily tricked into being complicit in the attack; (2) and having the HTTP server protect itself. The client adding a limit to its fetching frequency addresses part of (1). For the rest, there are two cases: either the host being pointed to is indeed a PvD Additional Information server (but not one working with the attacker), or else is some other server that has no idea about PvDs. If the case is the latter, trying to request the well-known PvD information won't work and will generate an error. That will let clients know that something's up and that they should stop trying to frequently fetch this file. If the case is the former, we can give advice to PvD Additional Information server to make sure it generates errors in cases that seem fishy. The client already validates that its RA prefixes match the additional info; and if the server validates that the client is coming from the expected prefix it manages, it can detect cases in which the attacker is trying to point load at it from other networks. This validation isn't *exactly* the same as requiring that the HTTP server is local, but it's similar, and gets the same benefits of limiting the scope. The main thing it allows is the HTTP server to be a bit behind the local network, but still be aware of the expected prefixes, etc. Thanks, Tommy > On Jan 22, 2020, at 8:07 AM, Ted Lemon <[email protected]> wrote: > > On Jan 22, 2020, at 10:53, Tommy Pauly <[email protected]> > wrote: >> 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. > > But does this help with the problem Adam is talking about? The attack is > coming from the RA. A rogue RA will not be in control of the network > operator. So the mitigation has to be on the recipient of the RA, I think. > > So your suggestion to abandon the query of the host gets a bad answer sounds > okay-ish, but probably we could do better by randomizing the query time on > the client and the like. > > Beyond that, is there any way to limit the scope of the query so that the > attack isn’t useful? My first instinct about this is that the attack isn’t > very useful because it requires an attacker on the local net, but we’ve seen > the power of the Mira attack; this would be a significant increase in these > attack’s effectiveness. > > Requiring the http listener to be local could make this pretty useless as an > attack. It’s inconvenient, but probably doable. Is there a reason not to do > it? > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
