8 ms·

> Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could b

> Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. That would be idiotic not just because unrusted parties can use those addresses, but more importantly because those are more or less terrible hacks that should be avoided completely if possible. You rather should have globally unique addresses on your internal network if you can, which would just break this. > Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. It's the internet, not "the home network and the cloud". What is needed is a way to establish a trust relationship between two devices that you have control over. Where those devices happen to be connected to the internet should be absolutely irrelevant. There might be an argument to be had to maybe support for a simplified peering procedure on a local network might be a good idea--but the point is that once the trust trelationship is established, you should be able to move your client device to a different network on the other side of the planet and still be able to talk to your device on your home network.

dcow 9y ago
I guess you missed the whole IPv6 scoped addressing architecture memo.
- zAy0LfpBZLC8mAC 9y ago
  Like what specifically?
  - dcow 9y ago
    A) Scopes aren't a hack they're part of the protocol. B) Scopes are exactly: "the global internet and the home". Considering those things why should it be absurd if I want to secure my home scope at the application layer too? IPv6 is literally designed to allow for this. Browsers are the things that are being stubborn. If IPv6 is just a terrible collection of hacks then we need a new version and fast before everyone get stuck on v6 for the next 50 years....
    - zAy0LfpBZLC8mAC 9y ago
      What scopes specifically would you suggest are "the global internet and the home" in the sense that is applicable here?
      - dcow 9y ago
        In IPv6 one interface has many addresses. Each one can have: 1. global addresses, 2. rotating temporary global addresses, 3. universal local addresses (one for each site), and 4. a link-local address (required). The first 3 now technically reside in the global scope. ULAs used to be called site-local and had their own scope, but they were restructured to basically be fancy UUIDs and their scope abolished and merged with the global scope. Link-local is still its own scope. Although both are globally scoped, there's a difference between a global IPv6 address and a ULA. The global is globally routeable and prefixes are organized regionally and delegated to allow hierarchical routing while ULAs have arbitrary prefixes (not suitable for global routing) and are not supposed to be forwarded to interfaces outside their subnet. So to answer your question, for local communications in your home that you didn't want leaving your network, you would use ULAs. You could use link-local addresses if your home was all on the same l2 link, but the generally preferred solution is to use ULAs so you don't leak protocol details upwards and so you can leverage l3 tunnels. Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. If you want DNS on your home site you simply run a local DNS server that resolves your local names and is configured to forward unknown names to the global DNS. IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution.
        zAy0LfpBZLC8mAC 9y ago
        > 2. rotating temporary global addresses, Well, not disagreeing that you can have those, but why are you mentioning that specifically for "global addresses", but not for ULA? > while ULAs have arbitrary prefixes (not suitable for global routing) How are ULA prefixes different from PI allocations as far as suitability for global routing is concerned? > and are not supposed to be forwarded to interfaces outside their subnet. Would you mind pointing to the normative source for this forwarding policy? > Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. Would you mind pointing to the normative source for this? > IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution. But you said that ULA are global scope (which they are, I agree), so what does this have to do with scoped addresses? Also, which void exactly does killing NAT leave that needs filling (and that then supposedly is filled by ULA)?
boomlinde 9y ago
> but more importantly because those are more or less terrible hacks that should be avoided completely if possible Seems quite unavoidable with IPv4, or what is the hack you're referring to specifically? > That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. What is the reason against? It's not like the idea of a privately managed network in which you trust all peers is novel or rare. Most people have a network in their home that they manage for themselves or for their family. It's the perfect scope for IoT devices. > It's the internet, not "the home network and the cloud". 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. 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. 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". > What is needed is a way to establish a trust relationship between two devices that you have control over. 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? > Where those devices happen to be connected to the internet should be absolutely irrelevant. Agreed, but the current conundrum is that they need to be connected to the internet if you want to use a central certificate authority.
- 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.

dcow 9y ago

I guess you missed the whole IPv6 scoped addressing architecture memo.

zAy0LfpBZLC8mAC 9y ago
Like what specifically?
- dcow 9y ago
  A) Scopes aren't a hack they're part of the protocol. B) Scopes are exactly: "the global internet and the home". Considering those things why should it be absurd if I want to secure my home scope at the application layer too? IPv6 is literally designed to allow for this. Browsers are the things that are being stubborn. If IPv6 is just a terrible collection of hacks then we need a new version and fast before everyone get stuck on v6 for the next 50 years....
  - zAy0LfpBZLC8mAC 9y ago
    What scopes specifically would you suggest are "the global internet and the home" in the sense that is applicable here?
    - dcow 9y ago
      In IPv6 one interface has many addresses. Each one can have: 1. global addresses, 2. rotating temporary global addresses, 3. universal local addresses (one for each site), and 4. a link-local address (required). The first 3 now technically reside in the global scope. ULAs used to be called site-local and had their own scope, but they were restructured to basically be fancy UUIDs and their scope abolished and merged with the global scope. Link-local is still its own scope. Although both are globally scoped, there's a difference between a global IPv6 address and a ULA. The global is globally routeable and prefixes are organized regionally and delegated to allow hierarchical routing while ULAs have arbitrary prefixes (not suitable for global routing) and are not supposed to be forwarded to interfaces outside their subnet. So to answer your question, for local communications in your home that you didn't want leaving your network, you would use ULAs. You could use link-local addresses if your home was all on the same l2 link, but the generally preferred solution is to use ULAs so you don't leak protocol details upwards and so you can leverage l3 tunnels. Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. If you want DNS on your home site you simply run a local DNS server that resolves your local names and is configured to forward unknown names to the global DNS. IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution.
      - zAy0LfpBZLC8mAC 9y ago
        > 2. rotating temporary global addresses, Well, not disagreeing that you can have those, but why are you mentioning that specifically for "global addresses", but not for ULA? > while ULAs have arbitrary prefixes (not suitable for global routing) How are ULA prefixes different from PI allocations as far as suitability for global routing is concerned? > and are not supposed to be forwarded to interfaces outside their subnet. Would you mind pointing to the normative source for this forwarding policy? > Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. Would you mind pointing to the normative source for this? > IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution. But you said that ULA are global scope (which they are, I agree), so what does this have to do with scoped addresses? Also, which void exactly does killing NAT leave that needs filling (and that then supposedly is filled by ULA)?

boomlinde 9y ago

> but more importantly because those are more or less terrible hacks that should be avoided completely if possible Seems quite unavoidable with IPv4, or what is the hack you're referring to specifically? > That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. What is the reason against? It's not like the idea of a privately managed network in which you trust all peers is novel or rare. Most people have a network in their home that they manage for themselves or for their family. It's the perfect scope for IoT devices. > It's the internet, not "the home network and the cloud". 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. 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. 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". > What is needed is a way to establish a trust relationship between two devices that you have control over. 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? > Where those devices happen to be connected to the internet should be absolutely irrelevant. Agreed, but the current conundrum is that they need to be connected to the internet if you want to use a central certificate authority.

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.