Re: [sunset4] to summarize Lorzeno's "drive-by" attack on draft-ietf-sunset4-noipv4

[Simon Perreault <[e-mail]>]

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