Re: [Int-area] Adam Roach's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

On Jan 22, 2020, at 11:44 AM, Tommy Pauly <[e-mail]> wrote:
> 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.

For a DDoS attack, if you get to (2) you are already somewhat dead.

> 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.

If the client has to contact the server to see that it’s an invalid server, then you have a DDoS attack.   I think if you do what you suggest, then the scope of the DDoS attack will be limited, to the extent that the server can at least say “you got the wrong number” and the client can then cache the info in the RA as “bogus” for some period of time, so that the DDoS is relatively brief.  But the server still needs to be able to answer in order for this to work.

It would be nice if there were a way for the client to validate the server information before contacting it.   I’m not convinced there’s a way to do that, but maybe some kind of DNSSEC info that has to be fetched first?   Of course, that could also be used as an attack vector, since the RA can include an RDNSS option.

Adam, do you think that randomizing the client connect time is enough to mitigate a Mira-style attack, when accompanied with the other mitigations Tommy has suggested?