Last week I had the pleasure to participate at the first RIPE IoT Roundtable Meeting in Leeds (thanks! to Marco Hogewoning for organising it). It was a day with many fruitful discussions. I particularly enjoyed Robert Kisteleki‘s talk on RIPE NCC’s own design & (security) process considerations in the context of RIPE Atlas (at TR17 NGI there was an intro to Atlas, too).
In this post I’d like to quickly lay out the main points of my own contribution on “Balanced Security for IPv6 CPE Revisited” (the slides can be found here).
Let’s assume in the following that there are “home networks” which are connected to and (somewhat) separated from the Internet by means of “Residential Internet Gateways” (this is the term that RFC 6092 uses) which in turn in a common service model & terminology are also called “CPEs” (Customer Premises Equipment). For the discussion below let’s also keep this quote from RFC 6092 in mind:
“The reader is cautioned always to remember that the typical residential or small-office network administrator has no expertise whatsoever in Internet engineering. Configuration interfaces for router/gateway appliances marketed toward them should be easy to understand and even easier to ignore. In particular, extra care should be used in the design of baseline operating modes for unconfigured devices, since most devices will never be changed from their factory configurations.”
In those home networks we commonly find two broad categories of devices:
- Desktop/laptop system which are used in an interactive manner by humans. Most OSs on these systems have some kind of auto-update mechanisms and as of today they generally display some level of security maturity, e.g. there’s not many services running by default and those which are (running) usually require some proper authentication.
- IoT devices of various types which have quite different properties (many of those are headless, don’t have proper auto-update and quite some have default passwords and/or still run services not to be found in the above category like Telnet).
Also there’s some notable other properties of IoT devices in the home which we should keep in mind (see also these slides from the 2016 ERNW Insight IoT Summit):
- the home’s inhabitants might not even know of their (the devices’) existence. Think of smart meters (which are activated/synched when moving in and forgotten afterwards) or stuff your kids buy (e.g. speakers for their smart phones).
- the devices might have a lifetime much longer than traditional desktop computers. Also there might be a relationship between the lifetime and warranty/liability periods so for example patches for specific models might no longer be provided after a certain point of time.
- and, most importantly, there’s the aspect of interaction between a device (plus its network stack) and the physical world. The malfunction of a device might lead to situations where no power is available, the heating fails, doors do not work in an intended way (may not open or not close) etc.
The main implication, for our discussion, of IPv6 coming to such home networks is that the devices then will have global, fully routable addresses (as opposed to RFC 1918 addresses combined with NAT44 in the current/legacy IPv4 networks).
Some people argue that this does not necessarily mean that an attacker or a worm can actually reach those devices due to the large address space of a /64 and the fact that the devices will most probably have (somewhat) random addresses due to RFC 4941/Privacy Extensions or RFC 7217.
Not everybody in the IPv6 community follows this reasoning though, as malware might also use “smart scanning” (for approaches see RFC 7707 by Fernando Gont and Tim Chown) and there was the case of shodan.io actively infiltrating ntp.org IPv6 pools for scanning purposes.
Besides this technical angle I’d like to emphasize that, due to the stateful nature of NAT44 (inbound connections usually can not be established) consumers might have developed a certain mental model when it comes to their (home) networks and devices. This mental model might be along the lines of “my home is my castle” and it might imply thinking like “here’s my little private network and over there [behind the CPE, from a user’s perspective] is the savage Internet, and while I can get data from there they can’t easily enter my little private sphere over here”.
This mental model might lead to all types of behavior and I think one must be quite careful with steps which create a posture which in reality is technically very different from users’ expectations.
Players in the IoT Ecosystem
From a high level perspective these actors contribute in the IoT/Smart Home ecosystem in one way or another:
- Vendors (of devices)
- Providers (“bringing Internet to the home”)
- Users
- All types of 3rd parties providing “value added services”.
They might have different motivations/incentives:
- Vendors: be quick (to market), cheap and easy-to-use.
- Users: who knows?
- 3rd Parties: act in a (minimum) compliant way, make money.
- Providers: create revenue, hence act in an operationally feasible way. maybe others, too => see below.
Now a/the crucial question for us (as the RIPE community where European providers have joined) can be formulated as follows: is there an ethical obligation to protect users? [and, if so, in which way?]
Actually this is a quite old debate (some elements of it can be found in this presentation I gave at a conference in Singapore in 2007). At the time quite a few providers took a “mere conduit” stance which can be paraphrased as “we only transport packets from one point to another, it’s not our role to interfere with those in any way”.
However, in 2017 and considering the way the Internet has developed, I think that we/the RIPE community can no longer that take position. I mean if we don’t contribute to protect home networks & their [IoT] devices, who else will? We/the providers have the technical means and skills – and hence the responsibility – to contribute to a safer Internet (of Things) ecosystem.
One area where this contribution can manifest is the security-related (default) configuration of CPEs (of course only when those are furnished by the providers themselves), namely the configuration of filtering of (inbound) traffic. There are three main approaches when it comes to such filtering:
- Do nothing (no filtering at all). To the best of my knowledge a few providers act like this (e.g. I hear the Greek provider Forthnet does this). On technical mailing lists usually there are some people who like this approach, but *they* have the experience & expertise to evaluate risks and to secure stuff behind the CPE (as opposed to 99.9% of users/consumers who don’t).
- Filter pretty much all inbound connections. This is along the lines of the above cited RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service whose (50!) recommendations can be summarized as “Block inbound stuff which doesn’t have state except some ICMPv6 messages and IPsec”. From my perspective quite some providers (the majority?) somewhat follow these lines.
- Something in between which usually can be described as “Allow most inbound stuff, but filter ‘known bad’ stuff”. Evidently this requires some weighting & trade-offs (and, ofc, this can be abused for censorship purposes but this is another discussion). This approach and a real-life example of some operators were described in the Internet-Draft [ID] “Balanced Security for IPv6 Residential CPE. draft-ietf-v6ops-balanced-ipv6-security” authored, amongst others, by Eric Vyncke from Cisco and Swisscom’s Martin Gysi. It should be noted that this includes/foresees also that technically savvy users can easily modify/disable this behavior on the CPE.
In general I have quite some sympathy for the “balanced” approach as it can provide some reasonable protection for home networks and their IoT devices (for example the main infection vector of the Mirai Botnet, which was Telnet, would have been blocked as Telnet is included in the suggested “Drop inbound” protocols as of the Internet-Draft) while at the same time not “destroying” the inherent E2E capabilities of IPv6. Unfortunately the draft was discarded in the IETF v6ops WG after revision 01. For those interested the (extensive) discussion on the mailing list can be found here. Overall I have to say that the arguments brought up against such filtering in that thread do, from my perspective, not really apply to today’s/tomorrow’s home networks full of IoT devices (see also the discussion at the end of my slides from the Leeds roundtable). I’d hence be happy to revive the discussion, and maybe even the ID (alternatively a BCOP document in another forum). Which is the exact purpose of this post 😉
Also I’d like to make you aware that currently a RIPE working group for IoT topics is undergoing constitution. The related discussion mailing list can be found here and here’s the draft agenda for the WG session at the upcoming RIPE75 meeting in Dubai.
Happy to get feedback on any channel and/or to have a conversation on the topic at some occasion, maybe in the course of the #TR18 NGI/IPv6 Security track.
Everybody have a great weekend,
Enno