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

[Adam Roach <[e-mail]>]

Thanks! The new text is good, but I don't think it's sufficient. I have 
two remaining concerns in particular:

  * The mitigation for wildcarded web hosts appears inadequate,
    especially given:
  * The mechanism clearly anticipates a scale where it can generate
    *single* short torrential burst sufficient to knock an average
    server over (hence the random delay mechanism for fetching data over
    HTTP). Given that fact, simple rate-limiting will never be enough if
    a single tight burst of traffic can be orchestrated.

The more I think about it, the more I believe the TXT-based opt-in 
solution I proposed in my earlier email is a reasonable approach to 
protect general-purpose web servers from PvD-client-based attacks.

One further comment inline below.

/a

On 1/22/20 15:17, Tommy Pauly wrote:
> Hi Adam,
>
> Thanks again for bringing this up! I've updated our text to include 
> mitigations for this attack. It can be found here 
> (https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25), but here's an 
> overview of the proposed text:
>
> In Section 4.1, I've added two new paragraphs. The first describes 
> time limits on fetching PvD info:
>
>     In addition to adding a random delay when fetching Additional
>     Information, hosts
>     MUST enforce a minimum time between requesting Additional Information
>     for a given PvD on the same network. This minimum time is RECOMMENDED
>     to be 10 seconds, in order to avoid hosts causing a
>     denial-of-service on the
>     PvD server. Hosts also MUST limit the number of requests that are
>     made to
>     different PvD Additional Information servers on the same network
>     within a short
>     period of time. A RECOMMENDED value is to issue no more than five PvD
>     Additional Information requests in total on a given network within
>     10 seconds.
>     For more discussion, see {{security}}.
>
> The second also makes clear the behavior to take in case of failure, 
> which will be the case for non-PvD web servers:
>
>
>     If the request for PvD Additional Information fails due to a TLS
>     error,
>     an HTTP error, or because the retrieved file does not contain
>     valid PvD JSON,
>     hosts MUST close any connection used to fetch the PvD Additional
>     Information,
>     and MUST NOT request the information for that PvD ID again for the
>     duration
>     of the local network attachment. For more discussion, see
>     {{security}}.
>
> In addition, I added text to the Security Considerations:
>
>     An attacker generating RAs on a local network can use the H-flag
>     and the PvD ID
>     to cause hosts on the network to make requests for PvD Additional
>     Information
>     from servers. This can become a denial-of-service attack if not
>     mitigated.
>

This doesn't really convey the amplification involved, which I think is 
highly relevant.


>     To mitigate
>     this attack, hosts MUST limit the rate at which they fetch a
>     particular PvD's
>     Additional Information, limit the rate at which they fetch any PvD
>     Additional
>     Information on a given local network, and stop making requests to
>     any PvD ID
>     that does not respond with valid JSON. Details are provided in
>     {{retr}}. This attack
>     can be targeted at generic web servers, in which case the host
>     behavior of stopping
>     requesting for any server that doesn't behave like a PvD
>     Additional Information server
>     is critical. For cases in which an attacker is pointing hosts at a
>     valid PvD Additional
>     Information server (but one that is not actually associated with
>     the local network),
>     the server SHOULD reject any requests that do not originate from
>     the expected IPv6
>     prefix as described in {{serverop}}.
>
> The existing text referenced here about server behavior is:
>
>     The server providing the JSON files SHOULD also check whether the
>     client address is contained by the prefixes listed in the additional
>     information, and SHOULD return a 403 response code if there is no
>     match.
>
> Let me know if this addresses your concerns!
>
> Best,
> Tommy
>
>> On Jan 21, 2020, at 9:26 PM, Adam Roach via Datatracker 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Thanks to the authors and working group for their work on this 
>> document.  I
>> have one major concern about the ability for this mechanism to be 
>> abused to
>> form DDoS attacks, described below. Unfortunately, while I have 
>> identified the
>> attack, I don't have an easy solution to propose that mitigates it 
>> satisfactorily.
>>
>> I also have a handful of mostly editorial comments on the document.
>>
>> ---------------------------------------------------------------------------
>>
>> §6:
>>
>> I was expecting to see a discussion of the DDoS attack that may 
>> result from a
>> large network (or a rogue host on such a network) sending out a PvD ID
>> containing the hostname of a victim machine, and setting the "H" flag.
>>
>> Since the messages used to trigger these HTTP connections are extremely
>> lightweight, unauthenticated UDP messages, and the resulting HTTP 
>> connections
>> require the exchange of a significant number of packets in addition to a
>> number of cryptographic operations, this is a very high ratio 
>> amplification
>> attack, both in terms of network and CPU resources.
>>
>> Given that the delay setting comes from the network instead of being
>> independently computed by the host, such an attack could be honed to be
>> particularly devastating.  Although it isn't a complete mitigation, one
>> approach to consider would be moving computation of the delay upper 
>> bound to
>> the host, or specifying a minimum upper bound of several minutes (where a
>> smaller value will cause the host to use this minimum upper bound).
>>
>> Regardless of how this is ultimately handled, I think this is a 
>> pretty severe
>> risk that needs addressing in the document prior to publication.
>>
>