<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2473 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml">
<!ENTITY RFC2827 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC3704 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml">
<!ENTITY RFC6092 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6092.xml">
<!ENTITY RFC6204 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6204.xml">
<!ENTITY RFC6583 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6583.xml">
<!ENTITY RFC6887 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6887.xml">
<!--ENTITY v6ops-simple-security PUBLIC "" 
	
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-cpe-simple-
security.xml"-->
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="info" docName="draft-ietf-v6ops-balanced-ipv6-security-01"
     ipr="trust200902">
  <front>
    <title abbrev="Balanced-CPEv6-security">Balanced Security for IPv6
    Residential CPE</title>

    <author fullname="Martin Gysi" initials="M" surname="Gysi">
      <organization>Swisscom</organization>

      <address>
        <postal>
          <street>Binzring 17</street>

          <code>8045</code>
          <city>Zürich</city>

          <country>Switzerland</country>

        </postal>

        <phone>+41 58 223 57 24</phone>

        <email>Martin.Gysi@swisscom.com</email>
      </address>
    </author>

    <author fullname="Guillaume Leclanche" initials="G" surname="Leclanche">
      <organization>Viagénie</organization>

      <address>
        <postal>
          <street>246 Aberdeen</street>

          <city>Québec, QC</city>


          <code>G1R 2E1</code>
          <country>Canada</country>
        </postal>

        <phone>+1 418 656 9254</phone>

        <email>guillaume.leclanche@viagenie.ca</email>
      </address>
    </author>

    <author fullname="Eric Vyncke" initials="E" role="editor" surname="Vyncke">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>De Kleetlaan 6a</street>

          <code>1831</code>
          <city>Diegem</city>


          <country>Belgium</country>
        </postal>

        <phone>+32 2 778 4677</phone>

        <email>evyncke@cisco.com</email>
      </address>
    </author>

    <author fullname="Ragnar Anfinsen" initials="R" surname="Anfinsen">
      <organization>Altibox</organization>

      <address>
        <postal>
          <street>Breiflaatveien 18</street>

          <code>4069</code>
          <city>Stavanger</city>

          <country>Norway</country>

        </postal>

        <phone>+47 93488235</phone>

        <email>Ragnar.Anfinsen@altibox.no</email>
      </address>
    </author>

    <date day="05" month="December" year="2013"/>

    <area>Operations</area>

    <workgroup>IPv6 Operations</workgroup>

    <keyword>CPE</keyword>

    <keyword>IPv6</keyword>

    <keyword>Security</keyword>

    <abstract>
      <t>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 documenting an existing 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 
      policy is a proposed set of rules that can be used as a default setting. 
      The set of blocked inbound and outbound ports is expected to be updated 
      as threats come and go.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Internet access in residential IPv4 deployments generally consists of
      a single IPv4 address provided by the service provider for each home.
      The 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 globally unique 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.
      </t>
      <t>This difference in residential default internet protection between 
      IPv4 and IPv6 is a major concern to a sizable number of ISPs and the
      security policy described in this document addresses this concern without
      damaging IPv6 end-to-end connectivity.
      </t>
      <t>
      The security model provided in this document is meant to be used as a
      pre-registered setting and potentially default one for IPv6 security in CPEs.
      The model departs from the "simple security" model described in <xref
      target="RFC6092"/> . It 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 policy has been
      deployed as a default setting in Switzerland by Swisscom for residential CPEs.
      </t>
      <t>This document can be applicable to off-the-shelves CPE as well as to managed
      Service Provider CPE or for mobile Service Providers (where it can be
      centrally implemented).</t>
    </section>

    <section anchor="threat" title="Threats">
      <t>For a typical residential network connected to the Internet over a
      broadband or mobile connection, the threats can be classified into:
      <list style="symbols">
          <t>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);</t>

          <t>denial of service by Neighbor Discovery cache exhaustion <xref
          target="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;</t>

          <t>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;</t>

          <t>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;</t>

          <t>exploiting a vulnerability in the host in order to get access to
          data or to execute some arbitrary code in the attacked host;</t>

          <t>trojanized host (belonging to a Botnet) can communicate via a
          covert channel to its master and launch attacks to Internet
          targets.</t>
        </list></t>
    </section>

    <section anchor="overview" title="Overview">
      <t>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 should be
      centrally updated, as threats are changing over time. It could also be a
      member of a list of pre-defined security policies available to an
      end-customer, for example together with "simple security" from <xref
      target="RFC6092"/> and a "strict security" policy denying access to all
      unexpected input packets.</t>

      <section anchor="rules" title="Rules for Balanced Security Policy">
        <t>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.</t>

        <t>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: <list style="numbers">
            <t>Rule RejectBogon: apply ingress filtering in both directions
            per <xref target="RFC3704"/> and <xref target="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), as described in
            Section 2.1 Basic Sanitation and Section 3.1 Stateless Filters
            of <xref target="RFC6092"/>;</t>

            <t>Rule AllowManagement: if the CPE is managed by the SP, then
            allow the management protocols (SSH, SNMP, syslog, TR-069, IPfix, ...)
            from/to the SP Network Operation Center;</t>

            <t>Rule ProtectWeakServices: drop all inbound and outbound packets
            whose layer-4 destination is part of a limited set (see <xref
            target="layer4-ACL"/>), the intent is to protect against the most
            common unauthorized access and avoid propagation of worms; an advanced residential user
            should be able to modify this pre-defined list;</t>

            <t>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 <xref target="RFC6092"/>.</t>

            <t>All requirements of <xref target="RFC6092"/> except REC-11,
            REC-18 and REC-33 must be supported.</t>
          </list></t>
      </section>

      <section anchor="layer4-ACL"
               title="Rules Example for Layer-4 Protection: Swisscom Implementation">

	<t>As of 2013, Swisscom has implemented the rule ProtectWeakService as
        described below. This is meant as an example and must not be followed blindly:
        each implementer has specific needs and requirements. Furthermore, the example
        below will not be updated as time passes, whereas threats will evolve.</t> 

        <texttable anchor="inbound_drops" title="Drop Inbound">

          <ttcol align="center">Transport</ttcol>

          <ttcol align="center">Port</ttcol>

          <ttcol align="center">Description</ttcol>

          <c>tcp</c>

          <c>22</c>

          <c>Secure Shell (SSH)</c>

          <c>tcp</c>

          <c>23</c>

          <c>Telnet</c>

          <c>tcp</c>

          <c>80</c>

          <c>HTTP</c>

          <c>tcp</c>

          <c>3389</c>

          <c>Microsoft Remote Desktop Protocol</c>

          <c>tcp</c>

          <c>5900</c>

          <c>VNC remote desktop protocol</c>
        </texttable>

        <texttable anchor="inbound_outbound_drops"
                   title="Drop Inbound and Outbound">
          <ttcol align="center">Transport</ttcol>

          <ttcol align="center">Port</ttcol>

          <ttcol align="center">Description</ttcol>

          <c>tcp-udp</c>

          <c>88</c>

          <c>Kerberos</c>

          <c>tcp</c>

          <c>111</c>

          <c>SUN Remote Procedure Call</c>

          <c>tcp</c>

          <c>135</c>

          <c>MS Remote Procedure Call</c>

          <c>tcp</c>

          <c>139</c>

          <c>NetBIOS Session Service</c>

          <c>tcp</c>

          <c>445</c>

          <c>Microsoft SMB Domain Server</c>

          <c>tcp</c>

          <c>513</c>

          <c>Remote Login</c>

          <c>tcp</c>

          <c>514</c>

          <c>Remote Shell</c>

          <c>tcp</c>

          <c>548</c>

          <c>Apple Filing Protocol over TCP</c>

          <c>tcp</c>

          <c>631</c>

          <c>Internet Printing Protocol</c>

          <c>udp</c>

          <c>1900</c>

          <c>Simple Service Discovery Protocol</c>

          <c>tcp</c>

          <c>2869</c>

          <c>Simple Service Discovery Protocol</c>

          <c>udp</c>

          <c>3702</c>

          <c>Web Services Dynamic Discovery</c>

          <c>udp</c>

          <c>5353</c>

          <c>Multicast DNS</c>

          <c>udp</c>

          <c>5355</c>

          <c>Link-Lcl Mcast Name Resolution</c>
        </texttable>
	
	<t>Choosing services to protect is not an easy task, and as of 2013
        there is no public service proposing a list of ports to use in such a policy.
        The Swisscom approach was to think in terms of services, by defining a list of
        services that are LAN-Only (ex: Multicast DNS) whose communication is denied by
        the policy both inbound and outbound, and a list of services that are known to
        be weak or vulnerable like management protocols that could be activated
        unbeknownst to the user.</t>

	<t>The process used to set-up and later update the filters is out of
        scope of this document.  The update of the specific rules could be done
        together with a firmware upgrade or by a policy update (for example using
        Broadband Forum TR-069).</t>

	<t>Among other sources, <xref target="DSHIELD"/> was used by Swisscom
        to set-up their filters. Another source of information could be the appendix A
        of <xref target="TR124"/>. The L4-filter as described does not block GRE
        tunnels (<xref target="RFC2473"/>) so this is a deviation from <xref
        target="RFC6092"/>.</t>

        <t>Note: the authors believe that with a dozen of rules only, a naive 
	and unaware residential subscriber would be reasonably protected. Of course,
        technically-aware susbcribers should be able to open other applications
        (identified by their layer-4 ports or IP protocol numbers) through
        their CPE using some kind of user interface or even to select a
        completely different security policy such as the open or 'closed'
        policies defined by <xref target="RFC6092"/>. This is the case in the 
        Swisscom deployment.</t> 
      
        <t>It is worth mentioning that PCP (<xref target="RFC6887"/>), UPnP 
        (<xref target="IGD"/>) and similar protocols can also be used to dynamically 
        override the default rules.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>There are no extra IANA consideration for this document.</t>
    </section>

    <section title="Security Considerations">
      <t>The security policy protects from the following type of attacks:<list style="symbols">
          <t>Unauthorized access because vulnerable ports are blocked</t>
        </list>
	Depending on the extensivity of the filters, certain vulnerabilities
        could be protected or not. It does not preclude the need for end-devices to 
        have proper host-protection as most of those devices (smartphones, laptops, etc.)
        would anyway be exposed to completely unfiltered internet at some point of
        time. The policy addresses the major concerns related to the loss of stateful
        filtering imposed by IPV4 NAPT when enabling public globally reachable IPv6 
        in the home.</t>
        <t>To the authors' knowledge, there has not been any incident related
        to this deployment in Swisscom network, and no customer complaints have 
        been registered.</t>

      <t>This set of rules cannot help with the following attacks: <list
          style="symbols">
          <t>Flooding of the CPE access link;</t>

          <t>Malware which is fetched by inside hosts on a hostile web site
          (which is in 2013 the majority of infection sources).</t>
        </list></t>
    </section>

    <section title="Acknowledgements">
      <t>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, Fred Baker, Lorenzo Colitti, Paul Hoffman, 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. </t> </section>
  </middle>

  <!-- =============================================================== -->

  <back>
    <references title="Informative References">
      &RFC2473;

      &RFC2827;

      &RFC3704;

      &RFC6092;

      &RFC6583;

      &RFC6887;

      <reference anchor="DSHIELD"
                 
target="https://secure.dshield.org/portreport.html?sort=records">
        <front>
          <title>Port report: DShield</title>

          <author>
            <organization>DShield</organization>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="TR124"
                 
target="http://www.broadband-forum.org/technical/download/TR-124.pdf">
        <front>
          <title>Functional Requirements for Broadband Residential Gateway
          Devices</title>

          <author>
            <organization>Broadband Forum</organization>
          </author>

          <date month="December" year="2006"/>
        </front>
      </reference>
        <reference anchor="IGD"
                 
target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf">
        <front>
          <title>WANIPConnection:2 Service</title>

          <author>
            <organization>UPnP Forum</organization>
          </author>

          <date month="December" year="20110"/>
        </front>
      </reference>
   </references>
  </back>
</rfc>
