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

[Michael Richardson]

Lorenzo spoke at the mic about a "drive-by" attack on an IPv4-only network.
I just want to make it clear about who and how people is impacted.
1) It's an IPv4-only network.
2) It has "modern" hosts, built after publication of draft-ietf-sunset4-noipv4.
3) It's open to some form of attackers.

So the "Starbucks" coffee-shop network of 2018.
It seems somewhat realistic to me.

I'm excluding home wifi networks, because I assume that they are either
layer-2 secure, or can identify brother/sister attacks through other means.

The attacker sends a number of IPv6 RAs per second.
They don't have to use a lot of bandwidth to do this; they just need to to
beat the newly booting/connecting host's emitting a DHCPv4 DISCOVER.

The host, ignoring that this is a hint, has to suppress *all* DHCPv4 DISCOVER
messages when it sees the RA noipv4 option.

If the host has successfully sent a DISCOVERY message, it might get an DHCPv4
OFFER, which may or may not be bogus (maybe the RA is legit and the DHCP is
bogus), and if it does, it would assume that there is v4, and would configure
IPv4.

I think that Lorenzo's concerns are real.
He feels, I think, that given the degree to which the noipv4 option would be
a hint to do DHCPv4 less often, rather than to turn it off completely, that
it would therefore become useless.

My understanding is that the problem with DHCPv4 discovers is that they are
layer-2 broadcasts, and just asking it killing some larger networks that were
trying to benefit from savings by deploying IPv6.

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Dan Wing]

Post by Michael Richardson
Lorenzo spoke at the mic about a "drive-by" attack on an IPv4-only network.
I just want to make it clear about who and how people is impacted.
1) It's an IPv4-only network.
2) It has "modern" hosts, built after publication of draft-ietf-sunset4-noipv4.
3) It's open to some form of attackers.

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?

-d

Post by Michael Richardson
So the "Starbucks" coffee-shop network of 2018.
It seems somewhat realistic to me.
I'm excluding home wifi networks, because I assume that they are either
layer-2 secure, or can identify brother/sister attacks through other means.
The attacker sends a number of IPv6 RAs per second.
They don't have to use a lot of bandwidth to do this; they just need to to
beat the newly booting/connecting host's emitting a DHCPv4 DISCOVER.
The host, ignoring that this is a hint, has to suppress *all* DHCPv4 DISCOVER
messages when it sees the RA noipv4 option.
If the host has successfully sent a DISCOVERY message, it might get an DHCPv4
OFFER, which may or may not be bogus (maybe the RA is legit and the DHCP is
bogus), and if it does, it would assume that there is v4, and would configure
IPv4.
I think that Lorenzo's concerns are real.
He feels, I think, that given the degree to which the noipv4 option would be
a hint to do DHCPv4 less often, rather than to turn it off completely, that
it would therefore become useless.
My understanding is that the problem with DHCPv4 discovers is that they are
layer-2 broadcasts, and just asking it killing some larger networks that were
trying to benefit from savings by deploying IPv6.
--
-= IPv6 IoT consulting =-
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

[Ted Lemon]

Post by Dan Wing
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. If your portable device is using any protocols that are susceptible to MiTM attacks, you shouldn't be connecting it to networks anyway, so we don't have to care about snooping, right? :)

So compare that to no-IPv4, where if this is propagated using RA or DHCPv6, it's possible to actually shut off the IPv4 connection and prevent the user from connecting over the IPv4 internet.

[Simon Perreault]

Post by Ted Lemon

Post by Dan Wing
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.

Simon

[*] http://resources.infosecinstitute.com/slaac-attack/

[Ted Lemon]

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

This is the MiTM attack I referred to in the previous message. If you are not using secure protocols, you are always vulnerable to MiTM.

[Dan Wing]

Post by Ted Lemon

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

This is the MiTM attack I referred to in the previous message. If you are not using secure protocols, you are always vulnerable to MiTM.

Considering RA Guard (RFC6105) and DHCP guard are necessary, so I don't see draft-ietf-sunset4-noipv4 creating a *new* risk.

I agree improving security of RA and DHCP (e.g., draft-ietf-dhc-sedhcpv6) are helpful, but in the intervening days between today and ubiquitous availability of deployable and secure RA and DHCP, a responsible network needs to block spoofed router advertisements from non-routers and prevent DHCP spoofing from non-DHCP servers.

Simon bought up an interesting point that an attacker abusing NOIPV4 needs only send a few packets and would have a lasting impact. The attacker need not stay on the network to have a lasting impact.

-d

[Ted Lemon]

Post by Dan Wing
Simon bought up an interesting point that an attacker abusing NOIPV4 needs only send a few packets and would have a lasting impact. The attacker need not stay on the network to have a lasting impact.

Yup, that's what I said too. Dunno why we're still talking about it! :)

[Simon Perreault]

Post by Ted Lemon

Post by Dan Wing
Simon bought up an interesting point that an attacker abusing NOIPV4 needs only send a few packets and would have a lasting impact. The attacker need not stay on the network to have a lasting impact.

Yup, that's what I said too. Dunno why we're still talking about it! :)

Because communication is hard! :)

Simon

[Michael Richardson]

Post by Simon Perreault

Post by Ted Lemon

Post by Dan Wing
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 <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Simon Perreault]

Post by Michael Richardson
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.

Post by Michael Richardson
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