In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote:
>Le 2014-04-15 09:56, Philip Homburg a écrit :
>>>> Right, to a certain extent that is true, of course; but not in the same
>>>> drive-by fashion where a single packet can put everyone offline (if the
>>>> option is not in the regular announcements).
>>>
>>> Sure it can. Just send them to a non-existing default gateway. Unless I
>>> misunderstood your point.
>> 
>> Right now, on any network that doesn't do IPv6, sending RAs has marginal 
>> effect. Certainly traffic within the site would be unaffected if there are
>> no IPv6 addresses in DNS.
>> 
>> With an RA that kills IPv4, that changes dramatically. Sounds like something
>> no sane OS vendor would enable by default.
>
>You can do the same today with a rogue DHCPv4 server.

No, you can't if the switches filter DHCP.

DHCP also has a completely different failure mode than RAs. To subvert
DHCP you have to wait for clients to send out DHCP discovers. For RA, you
just broadcast a couple of RAs.

A rogue DHCP server is annoying, but usually affects a few clients. A
rogue RA affects then entire subnet.

What you are doing is making IPv6 filtering mandatory on any network that
wants to do just IPv4.

>> From an OS perspective, I'd rather have this option in DHCPv4. That part
>> of the code knows about IPv4. Getting the IPv6 stack to tell the
>> IPv4 stack to shutdown is complicated
>
>Please tell me how this is complicated:
>
>$ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient
>
>For the systems I know, it would be trivial to implement. I could go and
>submit a patch to NetworkManager today.

Yes, and by the time this is fully configurable, you are talking about many
hundreds lines of code.

You are not going to just kill your DHCPv4 client each time you receive a
rogue RA. 

At least, not if you want people to use your OS.

>> and probably won't be implemented
>> until enough people bitch about it (and how stupid the IETF was) for quite
>> some time.
>
>This is an argument that always comes back with any proposal. I totally
>disagree with it. Anyone could code this up and submit a patch to
>Android. Then when the next release happens, bam, lots of support overnight.

Yes, and all security consultants will have a field day either selling patches
to disable this or selling switches that can filter RAs.

With your proposed code (actually killing dhclient) any mistake means that
you have to reboot all systems in the affected LAN. Which means that
any serious vendor will spend a lot of code making sure that the DHCP
is only suspended for a couple of RA intervals, which leads to a way
more complex interaction.


_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to