Simon Perreault <[email protected]> wrote: >> On Jul 25, 2014, at 9:05 PM, Dan Wing <[email protected]> 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 protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
pgp5Sxa0sRUOL.pgp
Description: PGP signature
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
