Balanced Security for IPv6 Residential CPE

Internet access in residential IPv4 deployments generally consists of a single IPv4 address provided by the service provider for each home. Residential CPE then translates the single address into multiple private IPv4 addresses allowing more than one device in the home, but at the cost of losing end-to-end reachability. IPv6 allows all devices to have a unique, global, IP address, restoring end-to-end reachability directly between any device. Such reachability is very powerful for ubiquitous global connectivity, and is often heralded as one of the significant advantages to IPv6 over IPv4. Despite this, concern about exposure to inbound packets from the IPv6 Internet (which would otherwise be dropped by the address translation function if they had been sent from the IPv4 Internet) remain. This document describes filtering functionality for an IPv6 CPE which departs from the "simple security" model described in . The intention is to provide an example of a security model which allows most traffic, including incoming unsolicited packets and connections, to traverse the CPE unless the CPE identifies the traffic as potentially harmful based on a set of rules. This model has been deployed successfully in Switzerland by Swisscom without any known security incident. This document is applicable to off-the-shelves CPE as well to managed Service Provider CPE or for mobile Service Providers (where it can be centrally implemented).

For a typical residential network connected to the Internet over a broadband or mobile connection, the threats can be classified into: denial of service by packet flooding: overwhelming either the access bandwidth or the bandwidth of a slower link in the residential network (like a slow home automation network) or the CPU power of a slow IPv6 host (like networked thermostat or any other sensor type nodes); denial of service by Neighbor Discovery cache exhaustion : the outside attacker floods the inside prefix(es) with packets with a random destination address forcing the CPE to exhaust its memory and its CPU in useless Neighbor Solicitations; denial of service by service requests: like sending print jobs from the Internet to an ink jet printer until the ink cartridge is empty or like filing some file server with junk data; unauthorized use of services: like accessing a webcam or a file server which are open to anonymous access within the residential network but should not be accessed from outside of the home network or accessing to remote desktop or SSH with weak password protection; exploiting a vulnerability in the host in order to get access to data or to execute some arbitrary code in the attacked host such as several against old versions of Windows; trojanized host (belonging to a Botnet) can communicate via a covert channel to its master and launch attacks to Internet targets.

The basic goal is to provide a pre-defined security policy which aims to block known harmful traffic and allow the rest, restoring as much of end-to-end communication as possible. This pre-defined policy can be centrally updated and could also be a member of a security policy menu for the subscriber.

These are an example set of generic rules to be applied. Each would normally be configurable, either by the user directly or on behalf of the user by a subscription service. This document does not address the statefulness of the filtering rules as its main objective is to present an approach where some protocols (identified by layer-4 ports) are assumed weak or malevolent and therefore are blocked while all other protocols are assumed benevolent and are permitted. If we name all nodes on the residential side of the CPE as 'inside' and all nodes on the Internet as 'outside', and any packet sent from outside to inside as being 'inbound' and 'outbound' in the other direction, then the behavior of the CPE is described by a small set or rules: Rule RejectBogon: apply ingress filtering in both directions per and for example with unicast reverse path forwarding (uRPF) checks (anti-spoofing) for all inbound and outbound traffic (implicitly blocking link-local and ULA in the same shot), this is basically the Section 2.1 Basic Sanitation and Section 3.1 Stateless Filters of ; Rule AllowManagement: if the CPE is managed by the SP, then allow the management protocols (SSH, SNMP, syslog, IPfix, ...) from/to the SP Network Operation Center if the management is not done by non-IP techniques such as the Broadband Forum TR-69; Rule ProtectWeakServices: drop all inbound and outbound packets whose layer-4 destination is part of a limited set (see ), the intent is to protect against the most common unauthorized access and avoid propagation of worms (even if the latter is questionable in IPv6); an advanced residential user should be able to modify this pre-defined list; Rule Openess: allow all unsolicited inbound packets with rate limiting the initial packet of a new connection (such as TCP SYN, SCTP INIT or DCCP-request not applicable to UDP) to provide very basic protection against SYN port and address scanning attacks. All transport protocols and all non-deprecated extension headers are accepted. This is a the major deviation from REC-11, REC-17 and REC-33 of . All requirements of except REC-11, REC-18 and REC-33 must be supported.

As an example only, the rule ProtectWeakService was implemented by Swisscom in 2013: Transport Port Description tcp 22 Secure Shell (SSH) tcp 23 Telnet tcp 80 HTTP tcp 3389 Microsoft Remote Desktop Protocol tcp 5900 VNC remote desktop protocol Transport Port Description tcp-udp 88 Kerberos tcp 111 SUN Remote Procedure Call tcp 135 MS Remote Procedure Call tcp 139 NetBIOS Session Service tcp 445 Microsoft SMB Domain Server tcp 513 Remote Login tcp 514 Remote Shell tcp 548 Apple Filing Protocol over TCP tcp 631 Internet Printing Protocol udp 1900 Simple Service Discovery Protocol tcp 2869 Simple Service Discovery Protocol udp 3702 Web Services Dynamic Discovery udp 5353 Multicast DNS udp 5355 Link-Lcl Mcast Name Resolution These example lists will probably evolve with the time as new protocols and new threats appear. The update of the specific rules could be done by firmware upgrade, policy update (for example by Broadband Forum TR-69). was used by Swisscom to set-up those filters. Another source of information could be the appendix A of . The above example does not block GRE tunnels () so this is a deviation from . Note: the authors believe that with this set the usual residential subscriber, the proverbial grand-ma, is protected. Of course, technical susbcribers should be able to open other applications (identified by their layer-4 ports or IP protocol numbers) through their CPE through some kind of user interface or even select a completely different security policy such as the open or 'closed' policies defined by .

There are no extra IANA consideration for this document.

The authors of the documents believe and the Swisscom deployment shows that the following attack are mostly stopped: Unauthorized access because vulnerable ports are blocked This set of rules cannot help with the following attacks: Flooding of the CPE access link; Malware which is fetched by inside hosts on a hostile web site (which is in 2013 the majority of infection sources).

The authors would like to thank several people who initiated the discussion on the ipv6-ops@lists.cluenet.de mailing list and others who provided us valuable feedback and comments, notably: Tore Anderson, Rajiv Asati, Lorenzo Colitti, Merike Kaeo, Simon Leinen, Eduard Metz, Martin Millnert, Benedikt Stockebrand. Thanks as well to the following SP that discussed with the authors about this technique: Altibox, Swisscom and Telenor.