> Your TV, fridge, printer, picture viewer, etc.. will be hiding on one of your residential 2^(128-56) = 4722366482869645213696 ipv6 addresses, so they woun't be that easy to find for an attacker..
They will be announcing themselves over discovery protocols. Otherwise it makes it impossible to find them and thus defeat the purpose of having them connected in the first place.
> I hope not..
It won't.
This is why we have things like uPNP and why things like uPNP won't go away.
Schaller: The long journey towards good free video conferencing
Posted Oct 15, 2012 19:59 UTC (Mon) by janfrode (subscriber, #244)
[Link]
> They will be announcing themselves over discovery protocols. Otherwise it makes it impossible to find them and thus defeat the purpose of having them connected in the first place.
Yes, they will be announcing on the local network. Not to the outside world. But yes, maybe we need to keep critical infrastructure (fridge) on separate subnets that are firewalled off, and real computers on open subnets.
BTW, nice perspective quote from rfc4864:
"At full-rate full-duplex 40 Gbps (400 times the typical 100
Mbps LAN, and 13,000 times the typical DSL/cable access link), it
takes over 5,000 years to scan the entirety of a single 64-bit
subnet."
As far as I've heard, the current IPv6 providers are divided on this issue. Some give their customers stateful firewall by default, others offer but don't enable by default. RFC6092 suggest that it's OK to have the CPE firewall default off/transparent.
Schaller: The long journey towards good free video conferencing
Posted Oct 15, 2012 20:48 UTC (Mon) by raven667 (subscriber, #5198)
[Link]
>> They will be announcing themselves over discovery protocols. Otherwise it makes it impossible to find them and thus defeat the purpose of having them connected in the first place.
>Yes, they will be announcing on the local network. Not to the outside world. But yes, maybe we need to keep critical infrastructure (fridge) on separate subnets that are firewalled off, and real computers on open subnets.
In fact they could operate with fe80::/16 addresses only if it truly was a local-only service.
Home firewall/routers could also make it easy to whitelist particular hosts, similar to the "Server IP" feature in most contemporary devices, except valid for more than one device, while leaving a default policy of outbound flows only.
> "...5,000 years to scan the entirety of a single 64-bit
subnet.?
There are probably ways to optimize this greatly by choosing which ranges to scan in what order based on likely MAC addresses, or by stealing web server logs or other data to find lists of in-use addresses.
Schaller: The long journey towards good free video conferencing
Posted Oct 15, 2012 20:57 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
except that none of these systems are really local-only services.
If nothing else, I'll bet that every single one of them is going to want to do NTP lookups to set their clock. That will require hitting the Internet.
Schaller: The long journey towards good free video conferencing
Posted Oct 15, 2012 21:49 UTC (Mon) by martinfick (subscriber, #4455)
[Link]
True! It would be nice if all these nifty too powerfull, bufferbloat producing, home gateway routers could server ntp by default to internal networks. And that if only there were a default protocol (perhaps DHCP?) that would point these device to our internal NTP gateway, and if only our new devices would do this by default for us if the gateway advertises this, instead of always relying on an outbound connection! Anyone device vendors working on standardising this one yet?
Schaller: The long journey towards good free video conferencing
Posted Oct 15, 2012 21:57 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
If you use DHCP to allocate IPv6 addresses, this is possible, but the link-local addresses are defined as being created independantly of any DHCP server.
and once you get an IP address from the DHCP server, you now have a real IPv6 address that is accessible from anywhere on the Internet (unless you have a firewall or NAT device in place)
Schaller: The long journey towards good free video conferencing
Posted Oct 16, 2012 2:35 UTC (Tue) by elanthis (guest, #6227)
[Link]
Link local addresses can still use service discovery on the local network to find things like an NTP server. Link local addresses basically depend on service discovery to even be useful.
Also, a DHCP server does not guarantee a binary option between public Internet connectivity or the use of a firewall/NAT. There's nothing in the world that says a DHCP server can't assign local addresses (fc00::/7) that don't route over the 'Net. You'd need a truly bad ISP for attackers to even be able to send you packets to those addresses, or receive packets from those addresses.
Schaller: The long journey towards good free video conferencing
Posted Oct 16, 2012 2:36 UTC (Tue) by kevinm (guest, #69913)
[Link]
There is already a DHCP option defined for specifying NTP server addresses, and NTP also supports broadcasting a query on the local subnet. It would make sense for home routers to listen on the local subnet for NTP broadcast requests and reply to them.
Schaller: The long journey towards good free video conferencing
Posted Oct 15, 2012 22:01 UTC (Mon) by raven667 (subscriber, #5198)
[Link]
I understand that there is a reason these devices are being connected to the Internet so a truly local-only device is probably rare. One added point though is that the device could use is public address for client connections (NTP, download updates, DNS, etc.) and advertise its fe80:: address for management and local-only services using multicast-DNS as is standard now-a-days. That's very simple to implement and greatly reduces the attack surface for services that shouldn't be remotely accessible.
Schaller: The long journey towards good free video conferencing
Posted Oct 16, 2012 11:40 UTC (Tue) by nim-nim (subscriber, #34454)
[Link]
The perimeter defence will honour things like uPNP as long as no device does something stupid with it. Given how consumer gadgets are cobbled together that probably means never (I'd like to be proven wrong, but I think I have a pretty good idea of the measures taken by gadget producers to make sure the local intern does not take shortcuts while customizing the local android clone for their fridge)
If there was a way to make sure random third-party developers do not demand over-broad accesses just because they can, it avoids work and no one's looking android apps would install automatically without any 'do you really want to let the app do that' phase.