Balanced Security for IPv6 Residential CPE
draft-ietf-v6ops-balanced-ipv6-security-00

IPv6 Operations                                                  M. Gysi
Internet-Draft                                                  Swisscom
Intended status: Informational                              G. Leclanche
Expires: April 24, 2014                                         Viagenie
                                                          E. Vyncke, Ed.
                                                           Cisco Systems
                                                             R. Anfinsen
                                                                 Altibox
                                                        October 21, 2013

               Balanced Security for IPv6 Residential CPE
             draft-ietf-v6ops-balanced-ipv6-security-00.txt

Abstract

   This document describes how an IPv6 residential Customer Premise
   Equipment (CPE) can have a balanced security policy that allows for a
   mostly end-to-end connectivity while keeping the major threats
   outside of the home.  It is based on an actual IPv6 deployment by
   Swisscom and allows all packets inbound/outbound EXCEPT for some
   layer-4 ports where attacks and vulnerabilities (such as weak
   passwords) are well-known.  The blocked inbound ports is expected to
   be updated as threats come and go.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Gysi, et al.             Expires April 24, 2014                 [Page 1]
Internet-Draft           Balanced-CPEv6-security            October 2013

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Threats . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Rules for Balanced Security Policy  . . . . . . . . . . .   3
     3.2.  Rules example for Layer-4 Protection as Used by Swisscom    4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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 [RFC6092] . 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).

Gysi, et al.             Expires April 24, 2014                 [Page 2]
Internet-Draft           Balanced-CPEv6-security            October 2013

2.  Threats

   For a typical residential network connected to the Internet over a
   broadband or mobile connection, the threats can be classified into:

   o  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);

   o  denial of service by Neighbor Discovery cache exhaustion
      [RFC6583]: 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;

   o  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;

   o  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;

   o  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;

   o  trojanized host (belonging to a Botnet) can communicate via a
      covert channel to its master and launch attacks to Internet
      targets.

3.  Overview

   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.

3.1.  Rules for Balanced Security Policy

   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

Gysi, et al.             Expires April 24, 2014                 [Page 3]
Internet-Draft           Balanced-CPEv6-security            October 2013

   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:

   1.  Rule RejectBogon: apply ingress filtering in both directions per
       [RFC3704] and [RFC2827] 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 [RFC6092];

   2.  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;

   3.  Rule ProtectWeakServices: drop all inbound and outbound packets
       whose layer-4 destination is part of a limited set (see
       Section 3.2), 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;

   4.  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 [RFC6092].

   5.  All requirements of [RFC6092] except REC-11, REC-18 and REC-33
       must be supported.

3.2.  Rules example for Layer-4 Protection as Used by Swisscom

   As an example only, the rule ProtectWeakService was implemented by
   Swisscom in 2013:

         +-----------+------+-----------------------------------+
         | Transport | Port |            Description            |
         +-----------+------+-----------------------------------+

Gysi, et al.             Expires April 24, 2014                 [Page 4]
Internet-Draft           Balanced-CPEv6-security            October 2013

         |    tcp    |  22  |         Secure Shell (SSH)        |
         |    tcp    |  23  |               Telnet              |
         |    tcp    |  80  |                HTTP               |
         |    tcp    | 3389 | Microsoft Remote Desktop Protocol |
         |    tcp    | 5900 |    VNC remote desktop protocol    |
         +-----------+------+-----------------------------------+

                           Table 1: Drop Inbound

         +-----------+------+-----------------------------------+
         | 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  |
         +-----------+------+-----------------------------------+

                    Table 2: Drop Inbound and Outbound

   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).

   [DSHIELD] was used by Swisscom to set-up those filters.  Another
   source of information could be the appendix A of [TR124].  The above
   example does not block GRE tunnels ([RFC2473]) so this is a deviation
   from [RFC6092].

   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 [RFC6092].

Gysi, et al.             Expires April 24, 2014                 [Page 5]
Internet-Draft           Balanced-CPEv6-security            October 2013

4.  IANA Considerations

   There are no extra IANA consideration for this document.

5.  Security Considerations

   The authors of the documents believe and the Swisscom deployment
   shows that the following attack are mostly stopped:

   o  Unauthorized access because vulnerable ports are blocked

   This set of rules cannot help with the following attacks:

   o  Flooding of the CPE access link;

   o  Malware which is fetched by inside hosts on a hostile web site
      (which is in 2013 the majority of infection sources).

6.  Acknowledgements

   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.

7.  Informative References

   [DSHIELD]  DShield, "Port report: DShield", , <https://
              secure.dshield.org/portreport.html?sort=records>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment (CPE) for Providing
              Residential IPv6 Internet Service", RFC 6092, January
              2011.

Gysi, et al.             Expires April 24, 2014                 [Page 6]
Internet-Draft           Balanced-CPEv6-security            October 2013

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583, March 2012.

   [TR124]    Broadband Forum, "Functional Requirements for Broadband
              Residential Gateway Devices", December 2006, <http://www
              .broadband-forum.org/technical/download/TR-124.pdf>.

Authors' Addresses

   Martin Gysi
   Swisscom
   Switzerland

   Email: Martin.Gysi@swisscom.com

   Guillaume Leclanche
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Phone: +1 418 656 9254
   Email: guillaume.leclanche@viagenie.ca

   Eric Vyncke (editor)
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Phone: +32 2 778 4677
   Email: evyncke@cisco.com

   Ragnar Anfinsen
   Altibox
   Norway

   Email: Ragnar.Anfinsen@altibox.no

Gysi, et al.             Expires April 24, 2014                 [Page 7]