I do not think this is a new issue that should be fixed in this document. I have written that a couple times already. I do think that it would be nice to work on another document describing best practices to secure DHCP services.
-- Christian Huitema On Dec 7, 2020, at 6:01 PM, Bernie Volz (volz) <volz@xxxxxxxxx> wrote:
There really aren’t any. Clients can generate different client-id and request prefix after prefix.
However, as this document points out these relays usually have limits to what it may track (and likely it would drop those packets from reaching client).
In some deployments, the number of prefixes allowed behind a particular relay is limited (at server or relay). Other mitigations may be shorter leases as then it comes down to how many can be requested during that time.
The main question is what does this benefit anyone? It is a DoS but in general it has limited impact as prefixes tend to be topological, so it isn’t like you could assign all of the prefixes an ISP has — just what is allowed on that link.
Why do you think this is a new issue that needs to be fixed in this document?
In my experience we have not seen these kinds of attacks as they aren’t very useful. And it has been a dhcp issue since dhcpv4 (addresses were much more scarce).
We tried securing dhcpv6...but it isn’t an easy problem to solve.
- Bernie
On Dec 7, 2020, at 8:06 PM, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
On 12/7/2020 4:31 AM, Bernie Volz (volz) wrote:
FYI:
I understand that solutions like RA
Guard will in practice provide some protection, but the use of these solutions are
not discussed in RFC 8213. The DHCP WG might want to address that.
RFC8415’s security considerations is rather extensive and includes reference to many techniques to reduce the issues. 8213 was written while 8415 was under development.
In the context of the draft, I am concerned in particular with the "resource-exhaustion" DoS attack, through exhaustion of delegatable prefixes. The attack is mentioned in the security section of 8415, but I have not seen the proposed mitigation.
-- Christian Huitema
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
