Re: [homenet] Please review the No IPv4 draft
Simon Perreault simon.perrea...@viagenie.ca writes: Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user can already do this today without this extension. 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). Would it not be reasonable to add in a requirement that if a client has already received a DHCPv4 lease (or more generally, has been configured for IPv4 in some way), it will ignore requests to turn off the stack? -Toke signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Le 2014-04-15 07:28, Toke Høiland-Jørgensen a écrit : Simon Perreault simon.perrea...@viagenie.ca writes: Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user can already do this today without this extension. 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. Would it not be reasonable to add in a requirement that if a client has already received a DHCPv4 lease (or more generally, has been configured for IPv4 in some way), it will ignore requests to turn off the stack? I'd be fine with that. Thanks for the idea! 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Simon Perreault simon.perrea...@viagenie.ca writes: Sure it can. Just send them to a non-existing default gateway. Unless I misunderstood your point. My point was that if you do this, the next time the real gateway sends out an advertisement, connections are going to be restored. Whereas if the gateway doesn't speak this option, all the hosts are just going to shut down IPv4 and not come back up until someone realises this is what happened. Would it not be reasonable to add in a requirement that if a client has already received a DHCPv4 lease (or more generally, has been configured for IPv4 in some way), it will ignore requests to turn off the stack? I'd be fine with that. Thanks for the idea! Cool! :) -Toke signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 09:46:38 -0400 you wrote: Le 2014-04-15 07:28, Toke H=F8iland-J=F8rgensen a =E9crit : Simon Perreault simon.perrea...@viagenie.ca writes: = Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user can already do this today without this extension. = 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. 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 and probably won't be implemented until enough people bitch about it (and how stupid the IETF was) for quite some time. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
We are soliciting reviews for this SUNSET4 draft: http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 In a nutshell, it defines DHCPv6 and RA options indicating to the host that IPv4 is not available. It seems to me that options relating to IPv4 don't belong in RA/DHCPv6 -- they belong in DHCPv4. Having a degenerate DHCPv4 server that just NAKs every request would appear to solve all of the problems in Section 3. The main point is that having a dedicated DHCPv4-NAK-ing server avoids the need to configure all IPv6 routers with IPv4-related information -- a serious operational concern if you have many IPv6 routers on a single link. (To be fair, you might need a new DHCPv4 option that says do not try to contact any other DHCPv4 servers to solve your problems 3.1/3.2. But then, I'd like to see some operational experience that shows that it is a problem in practice.) -- Juliusz (who wishes people would stop dumping gazillions of unrelated options into existing protocols) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote: 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). This is a good point. Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for the lifetime of the configuration message that delivered it—e.g., the prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP information-requests, the information refresh timer interval. Since we're doing the IPv6 configuration protocol anyway, there's no damage done by continuing to rely on it to suppress IPv4 configuration. Would it not be reasonable to add in a requirement that if a client has already received a DHCPv4 lease (or more generally, has been configured for IPv4 in some way), it will ignore requests to turn off the stack? No, because this just leaves the client open to a different DoS attack. If you have rogue configuration protocols running on your network, you need to fix it. This just moves the problem around—it doesn't solve it. One thing that I think would make this less likely to happen would be to state that no-ipv4 must be present on all valid configuration states received on a particular interface in order for no-ipv4 to be valid for that interface. IOW, if you are getting rogue RAs that say no IPv4 and also a non-rogue RA that doesn't say no IPv4, the host assumes that IPv4 is permitted. This prevents a rogue RA from killing IPv4 connectivity even for the lifetime of that RA. Of course the downside to this is that if you have multiple advertisers on your link and they don't all agree, you lose, but again that's a configuration error that the admin can fix, and hence not something that needs to be addressed at a protocol level. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Having a degenerate DHCPv4 server that just NAKs every request would appear to solve all of the problems in Section 3. Actually no, this would create packet storms. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
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. 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. 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. 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Le 2014-04-15 11:17, Ted Lemon a écrit : On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Having a degenerate DHCPv4 server that just NAKs every request would appear to solve all of the problems in Section 3. Actually no, this would create packet storms. Correct, and just ignoring the requests would not make the clients shut up either. They periodically wake up and see if IPv4 has become available. There's no way to signal that IPv4 is not available. 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On 15.4.2014, at 17.07, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: We are soliciting reviews for this SUNSET4 draft: http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 In a nutshell, it defines DHCPv6 and RA options indicating to the host that IPv4 is not available. It seems to me that options relating to IPv4 don't belong in RA/DHCPv6 -- they belong in DHCPv4. Having a degenerate DHCPv4 server that just NAKs every request would appear to solve all of the problems in Section 3. The main point is that having a dedicated DHCPv4-NAK-ing server avoids the need to configure all IPv6 routers with IPv4-related information -- a serious operational concern if you have many IPv6 routers on a single link. (To be fair, you might need a new DHCPv4 option that says do not try to contact any other DHCPv4 servers to solve your problems 3.1/3.2. But then, I'd like to see some operational experience that shows that it is a problem in practice.) Disclaimer: I haven’t read the draft. I like the idea on high level, though. Certain not-quite-RFC-compliant DHCP clients send DISCOVER once every 3 seconds until end of the world. I’m not sure this would fix those, though. NAK isn’t probably what you want (due to it’s semantics). However, OFFER that doesn’t really offer anything + magic option that says IPv4 is dead is what I’d want. I would rather see this than RA options as well; that way, the DHCP state machine (if any) can decide how long it honors this request not to do stuff. It also keeps v4 and v6 decoupled which actually makes life much easier in some implementations. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Le 2014-04-15 11:15, Ted Lemon a écrit : On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote: 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). This is a good point. Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for the lifetime of the configuration message that delivered it—e.g., the prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP information-requests, the information refresh timer interval. Since we're doing the IPv6 configuration protocol anyway, there's no damage done by continuing to rely on it to suppress IPv4 configuration. Makes total sense. Will be added in the next revision. (One could even argue that this is implicit with any information received over DHCPv6 or RA, and that doing otherwise would be going against design principles of those protocols.) Thanks, 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Ted Lemon mel...@fugue.com writes: No, because this just leaves the client open to a different DoS attack. If you have rogue configuration protocols running on your network, you need to fix it. This just moves the problem around—it doesn't solve it. Well, assuming this stays as an RA option and not a DHCPv4 one, I don't think it will be unreasonable for someone running an IPv4-only network to assume that they don't have to worry about IPv6 configuration protocols disabling their IPv4. Having the exception that if IPv4 already works, don't disable it will make this assumption more likely to be true. As an example, consider a university campus network (or a conference network) running IPv4 only, and someone broadcasting an RA packet onto the open wireless. Suddenly everything goes offline and will stay that way (until the RA expires) since no legitimate RAs come along to tell hosts to turn IPv4 back on. One thing that I think would make this less likely to happen would be to state that no-ipv4 must be present on all valid configuration states received on a particular interface in order for no-ipv4 to be valid for that interface. IOW, if you are getting rogue RAs that say no IPv4 and also a non-rogue RA that doesn't say no IPv4, the host assumes that IPv4 is permitted. This prevents a rogue RA from killing IPv4 connectivity even for the lifetime of that RA. I would definitely think it would be a good idea to have option not present have the same semantics as option set to allow ipv4. Otherwise, those actually running dual-stack networks would have to upgrade just to keep this from potentially causing problems. -Toke signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 10:34 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Makes total sense. Will be added in the next revision. What about the other part? I think it works with the use model you have in mind: if you want some devices to do IPv4 and others not, you can advertise no IPv4 in the RA, and send no IPv4 by default in DHCP information requests, but send nothing to clients that you want to use IPv4, and then the attack-rejection heuristic I proposed would result in those clients using IPv4. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Sorry, missed an important part. Replying in full. Le 2014-04-15 11:15, Ted Lemon a écrit : On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote: 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). This is a good point. Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for the lifetime of the configuration message that delivered it—e.g., the prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP information-requests, the information refresh timer interval. Since we're doing the IPv6 configuration protocol anyway, there's no damage done by continuing to rely on it to suppress IPv4 configuration. Makes total sense. Will be added in the next revision. Would it not be reasonable to add in a requirement that if a client has already received a DHCPv4 lease (or more generally, has been configured for IPv4 in some way), it will ignore requests to turn off the stack? No, because this just leaves the client open to a different DoS attack. If you have rogue configuration protocols running on your network, you need to fix it. This just moves the problem around—it doesn't solve it. One thing that I think would make this less likely to happen would be to state that no-ipv4 must be present on all valid configuration states received on a particular interface in order for no-ipv4 to be valid for that interface. IOW, if you are getting rogue RAs that say no IPv4 and also a non-rogue RA that doesn't say no IPv4, the host assumes that IPv4 is permitted. This prevents a rogue RA from killing IPv4 connectivity even for the lifetime of that RA. So that means if you're running DHCPv6, and assuming you use RAs for provisioning at least the default gateway, you need to put the No-IPv4 option in both RA and DHCPv6. If we specify that then we could just kill the DHCPv6 option since it would then be useless. Of course the downside to this is that if you have multiple advertisers on your link and they don't all agree, you lose, but again that's a configuration error that the admin can fix, and hence not something that needs to be addressed at a protocol level. Agreed. 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 10:46 AM, Toke Høiland-Jørgensen t...@toke.dk wrote: As an example, consider a university campus network (or a conference network) running IPv4 only, and someone broadcasting an RA packet onto the open wireless. Suddenly everything goes offline and will stay that way (until the RA expires) since no legitimate RAs come along to tell hosts to turn IPv4 back on. Hm, okay, I guess that in order to address that use case you do need to have a DHCPOFFER override an IPv6 no IPv4 advertisement. However, this still creates a timing race during which an attack could occur. So I think that if you really want to prevent IPv4 being shut off on an IPv4-only network by an RA, you really need to have your own RA going out that offers no prefixes and doesn't say no IPv4 or else you need to filter IPv6 at layer 2 (which I tend to think is a really bad idea, since it prevents ad-hoc link-local use of IPv6). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 11:05 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Yes, and by the time this is fully configurable, you are talking about many hundreds lines of code. I completely disagree with your estimate. I think you are talking apples and oranges. Simon, you are assuming a functional configuration environment; in such an environment, the change would be fairly trivial. Philip, I think you are assuming the current status quo on linux, which is badly broken and requires massive amounts of work to make small changes. In that context, it probably is hundreds of lines of code. But that really needs to get fixed regardless of the outcome of this discussion. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 11:22 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: So that means if you're running DHCPv6, and assuming you use RAs for provisioning at least the default gateway, you need to put the No-IPv4 option in both RA and DHCPv6. If we specify that then we could just kill the DHCPv6 option since it would then be useless. No, the DHCPv6 option is useful for selectively enabling IPv4. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Le 2014-04-15 12:25, Ted Lemon a écrit : On Apr 15, 2014, at 11:22 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: So that means if you're running DHCPv6, and assuming you use RAs for provisioning at least the default gateway, you need to put the No-IPv4 option in both RA and DHCPv6. If we specify that then we could just kill the DHCPv6 option since it would then be useless. No, the DHCPv6 option is useful for selectively enabling IPv4. Wait wait wait. If I get what you mean: - RAs would always contain No-IPv4. - DHCPv6 would selectively contain No-IPv4 or not. Is that correct? It can work. But it's sooo ugly! And I can just imagine the headaches it could cause to a sysadmin trying to troubleshoot a connectivity issue... 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 12:05:59 -0400 you wrote: http://resources.infosecinstitute.com/slaac-attack/ When you have unfiltered L2 access, there are LOTS of evil things you can do. The world is not black and white. Rogue RAs are easy for hit and run attacks. Maybe I should already create 'ipv4begone'. Would be a nice way to reserve the wireless for yourself in busy wifi networks. In contract MITM attacks are much harder to pull off. Any don't really gain much compared to just sniffing the wifi. 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. So now, any RA daemon also has to know to start dhclient. So it is more than just your oneliner. 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. Not if you just suspend DHCP operation for a while... 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. Similar to what you describe here. There is of course an easy way out. Let this run its course and then write an informational RFC that allocates the required option for DHCPv4. More choices are always better... Let the OS vendors decide. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
I think it's important to read the draft, and understand section 5.3, about the v4-level. I think that the security implications in the document are understood by the authors, but simply not spelled out yet. I think that some additional text in 5.3 might help make it clearer that there might be competing v4-labels coming from different routers/DHCPv6 servers, and that really the one with the lowest value wins. Hosts that don't understand this option will continue to behave as if the option did not occur, and any device for which this option is implemented needs to think about how much credence they will put into it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 11:24:31 -0500 you wrote: I think you are talking apples and oranges. Simon, you are assuming a functio nal configuration environment; in such an environment, the change would be fair ly trivial. Philip, I think you are assuming the current status quo on linux, which is badly broken and requires massive amounts of work to make small chang es. In that context, it probably is hundreds of lines of code. But that really needs to get fixed regardless of the outcome of this discussion . I'm also thinking about the code base for an embedded system I maintain. And I can really do without more complex interactions between IPv6 and IPv4. Adding an IPv4 suspend option to DHCPv4, that's easy. Doing the same thing from IPv6 is a nightmare. In any system that does DHCPv4, suspending IPv4 for a while is a purely local interaction with the DHCPc4 client. If you implement it for the most common DHCPv4 clients, you can probably get it implemented in little time. On the other hand, if you need have RAs signal suspend and resume of IPv4 you are looking at rewriting the management code of lots of different Linux distibutions (including various embedded ones) and many operating systems. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Having a degenerate DHCPv4 server that just NAKs every request would appear to solve all of the problems in Section 3. Actually no, this would create packet storms. My bad -- I didn't actually check. So either an empty OFFER, as suggested by Markus, or an OFFER with a new *DHCPv4* option. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com wrote: On the other hand, if you need have RAs signal suspend and resume of IPv4 you are looking at rewriting the management code of lots of different Linux distibutions (including various embedded ones) and many operating systems. Yes. That will be a really good outcome. I'm sorry, but I have no sympathy for your protestations about DHCPv4 clients in embedded applications. If it's an RPi, you can run a full-featured DHCPv4/DHCPv6 implementation that works, so there's no excuse for running one that doesn't. If it's a tiny sensor, you want to use 6lowpan anyway, so you're not running DHCPv4 _or_ DHCPv6. And you also always have the option of just ignoring the option if you are implementing something that really is an edge case. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 12:09:48 -0500 you wrote: On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com wro te: On the other hand, if you need have RAs signal suspend and resume of IPv4 you are looking at rewriting the management code of lots of different Linux distibutions (including various embedded ones) and many operating systems. Yes. That will be a really good outcome. You really think people are going to rewrite Linux network config for some weird edge case? I'm sorry, but I have no sympathy for your protestations about DHCPv4 clients i n embedded applications. If it's an RPi, you can run a full-featured DHCPv4/D HCPv6 implementation that works, so there's no excuse for running one that does n't. If it's a tiny sensor, you want to use 6lowpan anyway, so you're not run ning DHCPv4 _or_ DHCPv6. And you also always have the option of just ignoring the option if you are implementing something that really is an edge case. Then you don't. I'm only saying that from my perspective, changing DHCPv4 is the best technical solution. Now of course, the IETF can pick the option that requires serious changes in many operating systems, creates very interesting attacks, etc. Then that's just too bad. Note, this is an edge case. Operating systems hardly benefit from this option, but they will get the full load of any security issues. So my guess is that staying on the RA/DHCPv6 route will just seriously delay the implementation of this option. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
I'm only saying that from my perspective, changing DHCPv4 is the best technical solution. Right, but you haven't given a technical argument to support that. You're being somewhat disingeneous here, Ted. We're arguing that information about IPv4 availability should not be carried by IPv6 RAs, since it avoids a number of very unpleasant incestuous interactions. That is most certainly a technical argument, however you care to define this particular term. Keeping the two stacks cleanly separated has a number of practical (technical?) advantages: - in modular operating systems (not only Linux), this avoids dodgy interactions between separate daemons; - administrators can debug IPv4 issues without having to delve into the IPv6 configuration, and vice versa; - once (if?) IPv4 is phased out, we won't need to carry obsolete IPv4-related options within the IPv6 protocols. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In message m1wabgi-...@stereo.hq.phicoh.net, Philip Homburg writes: In your letter dated Tue, 15 Apr 2014 13:20:19 -0500 you wrote: Right, but you haven't given a technical argument to support that. You've just said that it's convenient in a particular existing implementation, which is not in wide use, and which is already undergoing changes that will coincidentally make addressing this less inconvenient. So this isn't a good argument. Please describe how in OSX, OpenWRT, FreeBSD, Android, IOS, the various Windows version gracefully starting and stopping IPv4 from an RA works? They write code. There is already userland code that reacts to RA flags in FreeBSD to start dhcpv6. It's not hard to add yet another callback to stop/start dhcpv4. I suspect if I sat down to do this I could do code it in a day. This is not rocket science. I could do it from scratch with raw sockets in just about as much time. I just need to be able to see the RA's and know what interface they arrived on. I have code in nameservers that listens for interface changes on routing sockets and adjusts manages the sockets that the nameserver listens on. That took well under a day to write from scratch and is about as complicated. This is not hard to implement. I would presume the others are roughly the same when you have access to the development trees. Oh, maybe give one example of a documented clean architecture that can handle this including every possible boundary condition. In contrast, having a DHCPv4 client stop sending DISCOVERs upon reception of a particular reply packet is almost a no brainer. I guess you don't see this as a technical argument, so be it. If you think that introducing network protocol changes that can only be handl ed by a widely used OS by rewriting their network config is a good idea when there is an alternative the can be implemented cleanly today, then there is no point further arguing. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
slowly I've gotten to understand the numerous layer-2 and layer-3 savings by not having to have the whole DHCPv4 relay and broadcast processing occuring. Could you please explain that? Perhaps with some examples, or even actual empirical data? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
