Ballot for draft-ietf-dhc-dhcp4o6-saddr-opt
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Thanks to everyone involved for the work they did on this document. I agree with Alissa's request for the addition of privacy considerations. --------------------------------------------------------------------------- §7.2.1: > the client's IPv6 will change. E.g., if there is an IPv6 re- Nit: "...the client's IPv6 address will change." --------------------------------------------------------------------------- §9: > For such an attack to be effective, the attacker would need to know > both the client identifier and active IPv4 address lease currently in > use by another client. The risk of this can be reduced by using a > client identifier format which is not easily guessable, e.g., by > including a time component for when the client identifier was > generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2). I might be missing something here, but my understanding is that DHCP isn't confidential, and so attackers on the same segment might be able to observe another client's identifier and IPv4 address in the DHCP traffic itself (depending on the nature of the networking equipment). Even if this cannot be easily mitigated, I think it's worth mentioning. --------------------------------------------------------------------------- §10: > IANA is requested to update the entry for DHCPv6 Option S46_BR (90) > in the Option Codes table at https://www.iana.org/assignments/ > dhcpv6-parameters as follows: > > Old entry: > > | 90 | S46_BR | No | No | > > New entry: > > | 90 | S46_BR | Yes | No | This is a somewhat unconventional way to represent IANA actions. This format does not make sense in a vacuum; and, more importantly, and will lose meaning in the case that the corresponding registry table is ever expanded. I also note that the name is incorrect (S46_BR instead of OPTION_S46_BR), and that the Reference column is omitted (which is relevant, as I believe the intenion is to instruct IANA to add this document to the list of references). Please consider reformatting as: Old Entry: Value: 90 Description: OPTION_S46_BR Client ORO: No Singleton Option: No Reference: [RFC7598] New Entry: Value: 90 Description: OPTION_S46_BR Client ORO: Yes Singleton Option: No Reference: [RFC7598] [RFCxxxx] > IANA is also requested to make a new entry for > OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at > https://www.iana.org/assignments/dhcpv6-parameters: > > | TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes | Similarly: Value: TBD1 Description: OPTION_S64_BIND_IPV6_PREFIX Client ORO: Yes Singleton Option: Yes Reference: [RFCxxxx]
I think this document could benefit from some discussion of the privacy considerations associated with the new options specified in the document. E.g., if one were to apply the analysis in RFC 7844, what would the guidance be to clients that want to limit the disclosure of information about themselves? (It might be "don't use DHCP4o6," but even that is worth saying if that's the best advice available.)
I agree with Alissa's comment privacy comment. Please consider using the new normative keyword boilerplate from RFC 8174.
Section 7 It is also a prerequisite that the client has already learned a suitable IPv6 prefix to use for its local softwire endpoint using DHCPv6, RA/PIO or another mechanism. I think I'm confused. Is the OPTION_S46_BIND_IPV6_PREFIX option a way to obtain the "suitable IPv6 prefix" above? If so, then "prerequisite" may not be the best word to use here. Section 7.2.1 Across the lifetime of the leased IPv4 address, it is possible that the client's IPv6 will change. E.g., if there is an IPv6 re- numbering event. nit: The last sentence is a sentence fragment. Section 9 With address-binding mechanisms such as these we also try to consider the possibility of binding an unexpected address to an unsuspecting recipient, e.g., to direct a large flow of traffic to a victim unable to process it all. I did not see an immediate way for an attacker to do this, since it would seem like it would either require DHCPv4 to assign the same address twice or allow a duplicate v6/v4 softwire binding, but I am not sure I have the full picture in my head yet. It would be good to include some text on this class of attacks, even if it is just "redirecting existing flows to an unsuspecting victim is not possible because <reason>".
Thank you for addressing my DISCUSS