4 ms·

It's absurd that an IoT device contacts a server hundreds of miles away when I'm inside my house turning on my lights via wifi.

Domenic_S 10y ago
Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.
- api 10y ago
  We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4. "Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken. Here are some of the characteristics that would label a network as endpoint hostile: - "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere. - Symmetric NAT - Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config. - Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.) - Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.) - IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT). - Lack of support for local multicast or broadcast - Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL. - Badly implemented NAT ALGs for things like FTP and SIP that break other traffic. - Lack of uPnP or NAT-PMP support. - Mandatory proxy configuration. - Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc. Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons. I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.
  - ianlevesque 10y ago
    This is exactly why the use of a remote server exists in so many IoT devices. Widely deployed home APs, even in USA, come with device isolation on by default or even not disableable.
    - mwcampbell 10y ago
      I'm surprised that device isolation is common on home APs. Wouldn't that break some fairly mainstream things like Chromecast?
      - twr 10y ago
        Yes. In fact, the Chromecast setup apps suggest disabling isolation if it cannot be connected to. Broken multicast support also prevents setup.
    - api 10y ago
      Is there actually a good reason for this "feature" outside of airport and coffee shop WiFi? Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.
      - CaptSpify 10y ago
        IMO: this is actually a good default setting. Home-router designers should assume that things are hostile by default. Of course, it should be dead-simple to turn this off as well.
        api 10y ago
        I pretty vehemently disagree. We should be very reluctant to systematically break good things to protect badly written junk. Let badly written junk burn. Then people will learn it's junk and stop using it or the developers and vendors will be forced to fix it.
- voltagex_ 10y ago
  Same with the way Xbox One Streaming works. At least Sony has set up some kind of NAT traversal to allow proper remote play.

Domenic_S 10y ago

Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.

api 10y ago
We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4. "Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken. Here are some of the characteristics that would label a network as endpoint hostile: - "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere. - Symmetric NAT - Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config. - Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.) - Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.) - IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT). - Lack of support for local multicast or broadcast - Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL. - Badly implemented NAT ALGs for things like FTP and SIP that break other traffic. - Lack of uPnP or NAT-PMP support. - Mandatory proxy configuration. - Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc. Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons. I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.
- ianlevesque 10y ago
  This is exactly why the use of a remote server exists in so many IoT devices. Widely deployed home APs, even in USA, come with device isolation on by default or even not disableable.
  - mwcampbell 10y ago
    I'm surprised that device isolation is common on home APs. Wouldn't that break some fairly mainstream things like Chromecast?
    - twr 10y ago
      Yes. In fact, the Chromecast setup apps suggest disabling isolation if it cannot be connected to. Broken multicast support also prevents setup.
  - api 10y ago
    Is there actually a good reason for this "feature" outside of airport and coffee shop WiFi? Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.
    - CaptSpify 10y ago
      IMO: this is actually a good default setting. Home-router designers should assume that things are hostile by default. Of course, it should be dead-simple to turn this off as well.
      - api 10y ago
        I pretty vehemently disagree. We should be very reluctant to systematically break good things to protect badly written junk. Let badly written junk burn. Then people will learn it's junk and stop using it or the developers and vendors will be forced to fix it.
voltagex_ 10y ago
Same with the way Xbox One Streaming works. At least Sony has set up some kind of NAT traversal to allow proper remote play.