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

[Adam Roach <[e-mail]>]

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