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

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Aug 2014 16:23:52 -0400

Simon Perreault <[email-masked]> wrote:
    >> On Jul 25, 2014, at 9:05 PM, Dan Wing <[email-masked]> wrote:
    >>> Specifically, the network has to allow an arbitrary host to send an
    >>> IPv6 RA.  Doesn't that open the network to a pile of attacks,
    >>> including an attacker-controlled IPv6 DNS server (RFC6106) and
    >>> attacker-controlled IPv6 default route?
    >>
    >> It does, but if the network provides DHCP service and the attacker
    >> either fails to answer faster, or is prevented from acting as a DHCP
    >> server, then happy eyeballs will take care of the broken IPv6 service.

    > Dan didn't say "broken", he said "attacker-controlled", possibly (my
    > guess) thinking of the infamous "SLAAC attack" [*]. Happy eyeballs is
    > useless here.

    > The new vulnerability introduced by No-IPv4 over RA is the "drive by"
    > nature of the attack: contrary to the SLAAC attack, the attacker
    > doesn't need to remain on the network. It can shut off the victim's
    > IPv4 access quickly then drive away.

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.

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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Aug 2014 08:47:46 -0400

> 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.

> 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