Le 2014-08-02 16:23, Michael Richardson a écrit :
If the No-IPv4 is defined to mean: "reduce the frequency of your DISCOVER"
it seems that the attacker has to retransmit regularly... It seems to me
that if the machine has *no* network connectivity at all yet (no IPv6
either, which the IPv6 process listening to the No-IPV4 message would know),
then the node should be skeptical about the NoIP4 flag anyway.
Note that the equivalent for DHCPv6 has been published recently:
http://tools.ietf.org/html/rfc7083#section-4
That RFC's security considerations section says:
This document introduces one security consideration beyond those
described in RFC 3315. A malicious DHCPv6 server might cause a
client to set its SOL_MAX_RT and INF_MAX_RT parameters to an
unreasonably high value with the SOL_MAX_RT and INF_MAX_RT options,
which may cause an undue delay in a client completing its DHCPv6
protocol transaction in the case no other valid response is received.
Assuming the client also receives a response from a valid DHCPv6
server, large values for SOL_MAX_RT and INF_MAX_RT will not have any
effect.
I suppose that a SOL_MAX_RT for DHCPv4 would have the exact same
considerations.
My understanding of the goal is to reduce the amount of *broadcast* DHCPv4
traffic that cloggs up some networks' infrastructure, because nodes that
don't get IPv4, ask more and more often as they can't find it.
That's one of the goals. See here:
http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00#section-3
Simon
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
