Le 2014-04-15 11:48, Philip Homburg a écrit : > 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.
I see your point. But that's already necessary today. Remember the SLAAC attack? http://resources.infosecinstitute.com/slaac-attack/ When you have unfiltered L2 access, there are LOTS of evil things you can do. >>> 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. I completely disagree with your estimate. > 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. Again: if there's an attacker with unfiltered L2 access to your host, there are lots of things he can do today to DoS you. >>> 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. No, you can just re-send the No-IPv4 option with value 0. We added it specifically to re-enable IPv4 when it has been previously disabled by mistake. And this is one advantage of using IPv6 for signalling the absence of IPv4 service. If you use IPv4 instead, and you make a mistake, there's no going back. > 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. As discussed with Ted Lemon, the next revision will specify that the No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
