5 ms·
> Seems quite unavoidable with IPv4, or what is the hack you're referring to specifically? Well, yes, for most people it unfortunately is. But imagine if your
by zAy0LfpBZLC8mAC 9y ago
> Seems quite unavoidable with IPv4, or what is the hack you're referring to specifically?
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.
> What is the reason against?
What would be a reason for limiting the usefulness of your devices?
> It's not like the idea of a privately managed network in which you trust all peers is novel or rare.
Which is fine, but not a sensible assumption to make in an IP product. If you want to use it in a privately managed, trusted network, of course you should be able to, but the idea that an IP device should just refuse to work over IP if your IP happens to extend beyond your LAN is idiotic. That should be a matter of the network's policy, not of the device's hard-coded policy.
> That's an interesting notion, but unfortunately does not reflect reality of use or the design of existing internet protocols, or even the very core concept of the internet: interconnected networks.
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.
What was before the internet were separate local (and sometimes not so local) networks: You had all kinds of link-layer protocols, and then various higher-level protocols, usually specific to a given link-layer. The whole point of the internet was to add a common abstraction to all of those link layers protocols, precisely to eliminate any distinction between local or remote, ethernet or token ring, modem or ISDN, GSM or CDMA, an addressing layer that erased the distinction: If you had an IP address and the thing you wanted to communicate with had an IP address, you could, even if you were on token ring, your WAN link was ISDN, the backbone was ATM, the peer's WAN link was a dial-in modem and their LAN was ethernet. The point of IP is that you don't have to care, any IP address is as good as any other.
> I have a private network at home. My means to connect devices on this network to the internet is via a gateway which is assigned a single globally unique internet address by my service provider, and a locally unique address on the private network.
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).
> If at some point every device has its own global address and is accessible globally, it will be more accurate to assume that something is insecure if it communicates in the plain, but we're not there yet. What the browser is doing now is pretty much assuming an arbitrary level of "better safe than sorry".
Not sure I am getting your point!?
> Say, by sharing sharing keys over a network under your control, certified and authorized by a device you trust for pretty much everything else on that network?
Well, arguably you totally should not trust your router, they tend to be crap security-wise.
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.
> Agreed, but the current conundrum is that they need to be connected to the internet if you want to use a central certificate authority.
Well, yes?! But the solution is not to hard-code policies that prevent full use of IP.
- boomlinde 9y ago> 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