4 ms·

> Well, yes, for most people it unfortunately is. But imagine if your are one of the lucky ones who do have global IPv4 addresses everywhere. And now someone se

> Well, yes, for most people it unfortunately is. But imagine if your are one of the lucky ones who do have global IPv4 addresses everywhere. And now someone sells you a product that tells you "sorry, nice IPv4 network that you have there, but you have to install NAT and an RFC1918 network to use this IPv4 product". Not very sensible, is it? Same applies for IPv6 and ULA, obviously. Are you arguing from the assumption that my suggestions and any other form of establishing trust are mutually exclusive? If you're that lucky guy with a global address for your lightbulb, by all means use what's at your disposal to establish a trusted encrypted link between the device and the user in a convenient way. Not sure how that would prevent the vast majority using these on private networks with a different method of authentication and different criteria for trust. > Erm ... that's completely backwards? It unfortunately does not reflect the current use of IPv4 in particular due to NAT everywhere, but that certainly was not part of "the design of existing internet protocols", that was a hack due to lack of addresses. So, given the limited address range, it was clearly not designed for every person in the world to have an address, not to mention every appliance in your kitchen. The internet has grown rather organically and has adopted a broader use case. The infrastructure, protocols and best practices used on the internet now reflect this unanticipated use case. > Well, yes, unfortunately, that is the case nowadays. That is not how IP was meant to be used, and it's causing massive problems. If it weren't for lack of addresses, your home network should have a globally unique /24 or something (and it did, back in the day). How it was meant to be used is an artefact that stopped mattering some time in the 80s. > Not sure I am getting your point!? The point is that flagging plain http websites as "unsafe" makes a lot of assumptions about my network. They're not necessarily unsafe. In one case, it's on my apartment-wide LAN. In another case, it's connected by ethernet directly to the client. Neither of these are particularly exotic topologies. > But in any case, my point was that at most that should be a pairing mechanism. So, once the trust relationship is established, there should be no need to stay on the local network for further secure communication. Why not both? > Well, yes?! But the solution is not to hard-code policies that prevent full use of IP. Agreed? I'm not sure where you got the idea that I think that any of these things should prevent the full use of IP. Certainly not from anything I've said.

zAy0LfpBZLC8mAC 9y ago
> Are you arguing from the assumption that my suggestions and any other form of establishing trust are mutually exclusive? If you're that lucky guy with a global address for your lightbulb, by all means use what's at your disposal to establish a trusted encrypted link between the device and the user in a convenient way. Well, if that were a standardized way to establish trust, that necessarily would lead to vendors adopting it at the cost of suporting other kinds of setups? Also, it is very problematic to overload not globally routable addresses (also often misleadingly called "private addresses") with security semantics. While many home setups do have a sort-of security boundaries around RFC1918 subnets, there is absolutely no guarantee that that is the case. So not only would such a mechanism break "sane" (i.e., NAT-free) setups, it also would make otherwise perfectly fine and useful setups risky. Have a VPN link to another company that also uses RFC1918 space or ULA, and suddenly your IoT stuff starts trusting that other company. Or even just if you happen to have departments that aren't supposed to trust each other, and that happen to have a common ULA prefix, and now some devices simply assume trust where none is implied/make it impossible to use otherwise perfectly fine setups because of unjustified trust assumptions. Or simply a guest on your network. Or ... whatever else that can share non-globally routed address space with you without any trust implied. > So, given the limited address range, it was clearly not designed for every person in the world to have an address, not to mention every appliance in your kitchen. The internet has grown rather organically and has adopted a broader use case. Well, yes, but that wasn't because it was intended to be used with NAT, or anything else that was not a globally routable address for every device, but because it wasn't expected to gain that many users. > The infrastructure, protocols and best practices used on the internet now reflect this unanticipated use case. Which is an argument for what exactly? Especially with regards to IPv6 and ULA? > How it was meant to be used is an artefact that stopped mattering some time in the 80s. Why would that have stopped then? Again, in particular with regards to IPv6, which does not have the address scarcity that might have justified use of NAT and non-globally routed address space as a temporary workaround? > The point is that flagging plain http websites as "unsafe" makes a lot of assumptions about my network. ... just as not doing so does? If anything, it would be arbitrary to just exempt certain prefixes from security policies when there is not normative basis for such an exemption. I happen to have only globally routable IPv6 addresses on my LAN, but my LAN is indeed trusted, both wired and WiFi, using distinct /64s. But I also have a guest WiFi that is in the same IPv6 /48, which is not trusted. And I have a VPN link to a customer of mine that uses RFC1918 address space, which is absolutely not trusted. So, yes, it is "better safe than not safe". But it's exactly the opposite of arbitrary, in that it does not make any assumptions about your network, it provides security no matter what the details of your network, and using the exact same policy for everything. And it's hardly "better safe than sorry", given that this is all a result of being very sorry about all the crap that resulted from lack of security so far. > They're not necessarily unsafe. In one case, it's on my apartment-wide LAN. In another case, it's connected by ethernet directly to the client. Neither of these are particularly exotic topologies. Yeah, and how is your browser supposed to know that? > Why not both? What both?! > Agreed? I'm not sure where you got the idea that I think that any of these things should prevent the full use of IP. Certainly not from anything I've said. The question is not whether it should, but whether it would. Suppose browsers were to implement a policy of "RFC1918 and ULA are considered safe unencrypted and -authenticated". What would vendors of devices do? I guess we can agree that they would use that policy for config access, as it simplifies the design of their devices, right? Now, that would cover 99%+ of their current user base. Which probably means they won't bother providing an alternative mechanism. Which means (a) you can't use their devices in other setups and (b) their users are locked into such setups, which makes it impossible for, say, router vendors, to build more useful networking products that use the full potential of IP.

zAy0LfpBZLC8mAC 9y ago

> Are you arguing from the assumption that my suggestions and any other form of establishing trust are mutually exclusive? If you're that lucky guy with a global address for your lightbulb, by all means use what's at your disposal to establish a trusted encrypted link between the device and the user in a convenient way. Well, if that were a standardized way to establish trust, that necessarily would lead to vendors adopting it at the cost of suporting other kinds of setups? Also, it is very problematic to overload not globally routable addresses (also often misleadingly called "private addresses") with security semantics. While many home setups do have a sort-of security boundaries around RFC1918 subnets, there is absolutely no guarantee that that is the case. So not only would such a mechanism break "sane" (i.e., NAT-free) setups, it also would make otherwise perfectly fine and useful setups risky. Have a VPN link to another company that also uses RFC1918 space or ULA, and suddenly your IoT stuff starts trusting that other company. Or even just if you happen to have departments that aren't supposed to trust each other, and that happen to have a common ULA prefix, and now some devices simply assume trust where none is implied/make it impossible to use otherwise perfectly fine setups because of unjustified trust assumptions. Or simply a guest on your network. Or ... whatever else that can share non-globally routed address space with you without any trust implied. > So, given the limited address range, it was clearly not designed for every person in the world to have an address, not to mention every appliance in your kitchen. The internet has grown rather organically and has adopted a broader use case. Well, yes, but that wasn't because it was intended to be used with NAT, or anything else that was not a globally routable address for every device, but because it wasn't expected to gain that many users. > The infrastructure, protocols and best practices used on the internet now reflect this unanticipated use case. Which is an argument for what exactly? Especially with regards to IPv6 and ULA? > How it was meant to be used is an artefact that stopped mattering some time in the 80s. Why would that have stopped then? Again, in particular with regards to IPv6, which does not have the address scarcity that might have justified use of NAT and non-globally routed address space as a temporary workaround? > The point is that flagging plain http websites as "unsafe" makes a lot of assumptions about my network. ... just as not doing so does? If anything, it would be arbitrary to just exempt certain prefixes from security policies when there is not normative basis for such an exemption. I happen to have only globally routable IPv6 addresses on my LAN, but my LAN is indeed trusted, both wired and WiFi, using distinct /64s. But I also have a guest WiFi that is in the same IPv6 /48, which is not trusted. And I have a VPN link to a customer of mine that uses RFC1918 address space, which is absolutely not trusted. So, yes, it is "better safe than not safe". But it's exactly the opposite of arbitrary, in that it does not make any assumptions about your network, it provides security no matter what the details of your network, and using the exact same policy for everything. And it's hardly "better safe than sorry", given that this is all a result of being very sorry about all the crap that resulted from lack of security so far. > They're not necessarily unsafe. In one case, it's on my apartment-wide LAN. In another case, it's connected by ethernet directly to the client. Neither of these are particularly exotic topologies. Yeah, and how is your browser supposed to know that? > Why not both? What both?! > Agreed? I'm not sure where you got the idea that I think that any of these things should prevent the full use of IP. Certainly not from anything I've said. The question is not whether it should, but whether it would. Suppose browsers were to implement a policy of "RFC1918 and ULA are considered safe unencrypted and -authenticated". What would vendors of devices do? I guess we can agree that they would use that policy for config access, as it simplifies the design of their devices, right? Now, that would cover 99%+ of their current user base. Which probably means they won't bother providing an alternative mechanism. Which means (a) you can't use their devices in other setups and (b) their users are locked into such setups, which makes it impossible for, say, router vendors, to build more useful networking products that use the full potential of IP.