|
Hi Jen!
As noted in paragraph 3 of the Security Considerations, any attacker who can mount these attacks can already take down the whole DHCP system by other means, so these attacks do not reduce the security of the system. As such, I think it would be clearer to
note that DHCP is insecure unless special precautions are taken, and the P flag doesn't change that.
There is a long history of people being confused about the privacy properties of SLAAC and related techniques. For clarity, I think it would be worthwhile to reiterate that DHCPv6 may be inappropriate for privacy-sensitive clients. In general, I think we
tend to understate the privacy loss of IPv6 as compared to NAT. I would prefer that we emphasize these problems in our documents, to help us move toward stronger privacy in addressing.
On prefix length, it might make more sense to reference Section 8 of ietf-v6ops-dhcp-pd-per-device. Regardless, I find this logic unintelligible. I can understand a requirement that the client request a short enough prefix if it wants to use SLAAC internally.
I can understand a requirement that the network not exceed the client's requested prefix length. I can't understand a requirement that the network give the client more space than it asked for. If long prefixes are actually invalid (as implied in Section
8 of ietf-v6ops-dhcp-pd-per-device), then that should be the stated rationale, and the MUST should apply to the client, not the network.
--Ben
From: Jen Linkova <furry13@xxxxxxxxx>
Sent: Monday, September 30, 2024 7:13 AM To: ietf@xxxxxxxxxx <ietf@xxxxxxxxxx> Cc: draft-ietf-6man-pio-pflag.all@xxxxxxxx <draft-ietf-6man-pio-pflag.all@xxxxxxxx>; Last Call <last-call@xxxxxxxx>; 6man <ipv6@xxxxxxxx>; secdir@xxxxxxxx <secdir@xxxxxxxx> Subject: Re: [secdir] Secdir last call review of draft-ietf-6man-pio-pflag-09 Hi Ben, Thank you for the review! Comments inline. >Security Issues: >The security section is, if anything, too detailed, as it describes attacks that are not meaningful to the security of the system. I would shorten this section. Would you be able to elaborate on this? Currently the section describes: - the first paragraph: an attack vector which leads to service degradation or complete DoS for the endpoint; - second paragraph: an attack vector leading to DoS for the server infrastructure. Anything in particular you consider not very relevant for the security of the system? >The privacy considerations are important and are described appropriately. It >might be worth adding a note that privacy-conscious clients should consider not >implementing this specification. As the privacy section of both this draft and ietf-v6ops-dhcp-pd-per-device mentions, the privacy properties of the proposed solution are similar but better than ones of DHCPV6 IA_NA. So privacy-conscious clients should either consider implementing this specification instead of DHCPv6 IA_NA (or choose not to implement DHCPv6 at all, but such statement would be clearly out of scope of this particular draft..) >Other topics: >I was not able to see why prefix requests "MUST" be short enough for SLAAC. >Why would a host perform SLAAC within its own exclusively allocated prefix? If >the host is acting as a router for a network containing SLAAC clients, it can >request a larger prefix, but why is this mandatory for all hosts? This was discussed by the WG extensively. The reason is explained in the pd-per-device draft, so we added a reference to clarify that (we've just submitted -10). -- Cheers, Jen Linkova |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
