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
<[email protected] <mailto:[email protected]>> 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.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
