One document matched: draft-v6ops-vyncke-balanced-ipv6-security-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!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 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-v6ops-vyncke-balanced-ipv6-security-01.txt"
ipr="trust200902">
<front>
<title abbrev="Balanced-CPEv6-security">Balanced Security for IPv6
CPE</title>
<author fullname="Martin Gysi" initials="M" surname="Gysi">
<organization>Swisscom</organization>
<address>
<postal>
<street/>
<city/>
<country>Switzerland</country>
<code/>
</postal>
<phone/>
<email>Martin.Gysi@swisscom.com</email>
</address>
</author>
<author fullname="Guillaume Leclanche" initials="G" surname="Leclanche">
<organization>Swisscom</organization>
<address>
<postal>
<street/>
<city/>
<country>Switzerland</country>
<code/>
</postal>
<phone/>
<email>Guillaume.Leclanche@swisscom.com</email>
</address>
</author>
<author fullname="Eric Vyncke" initials="E" role="editor" surname="Vyncke">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<country>Belgium</country>
<code>1831</code>
</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/>
<city/>
<country>Norway</country>
<code/>
</postal>
<phone/>
<email>Ragnar.Anfinsen@altibox.no</email>
</address>
</author>
<date day="15" month="July" 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 based on an actual IPv6 deployment by Swisscom and
proposes to allow all packets inbound/outbound EXCEPT for some layer-4
ports where attacks and vulnerabilities (such as weak passwords) are
well-known.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Internet access in residential IPv4 deployments generally consist 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 firewall functionality for an
IPv6 CPE which departs from the "simple security" model described in
<xref target="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.</t>
<t>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).</t>
</section>
<section anchor="threat" title="Threats">
<t>For a typical residential network connected to the Internet over a
broadband 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 such as
several against old versions of Windows;</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 can be
centrally updated and could also be a member of a security policy menu
for the subscriber.</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.</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), this is basically
the Section 2.1 Basic Sanitation and Section 3.1 Stateless Filters
of <xref target="RFC6092"/>;</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 (even if
the latter is questionable in IPv6); 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 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 as Used by Swisscom">
<t>The rule ProtectWeakService can be implemented by using the
following suggestions as implemented by Swisscom in 2013:</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>This list should evolve with the time as new protocols and new
threats appear, <xref target="DSHIELD"/> is used by Swisscom to keep
those filters up to date. Another source of information could be the
appendix A of <xref target="TR124"/>. The above proposal 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 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 TCP or UDP ports) 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 <xref
target="RFC6092"/>.</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 authors of the documents believe and the Swisscom deployment
shows that the following attack are mostly stopped:<list style="symbols">
<t>Unauthorized access because vulnerable ports are blocked</t>
</list></t>
<t>This proposal 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 2012 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, notably: Tore
Anderson, Lorenzo Colitti, Merike Kaeo, Simon Leinen, Eduard Metz,
Martin Millnert, Benedikt Stockebrand.</t>
</section>
</middle>
<!-- =============================================================== -->
<back>
<!--references title="Normative References"-->
<!--/references-->
<references title="Informative References">
&RFC2473;
&RFC2827;
&RFC3704;
&RFC6092;
&RFC6583;
<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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:20 |