draft-ietf-v6ops-balanced-ipv6-security-00.txt   draft-ietf-v6ops-balanced-ipv6-security-01.txt 
IPv6 Operations M. Gysi IPv6 Operations M. Gysi
Internet-Draft Swisscom Internet-Draft Swisscom
Intended status: Informational G. Leclanche Intended status: Informational G. Leclanche
Expires: April 24, 2014 Viagenie Expires: June 8, 2014 Viagenie
E. Vyncke, Ed. E. Vyncke, Ed.
Cisco Systems Cisco Systems
R. Anfinsen R. Anfinsen
Altibox Altibox
October 21, 2013 December 05, 2013
Balanced Security for IPv6 Residential CPE Balanced Security for IPv6 Residential CPE
draft-ietf-v6ops-balanced-ipv6-security-00.txt draft-ietf-v6ops-balanced-ipv6-security-01
Abstract Abstract
This document describes how an IPv6 residential Customer Premise This document describes how an IPv6 residential Customer Premise
Equipment (CPE) can have a balanced security policy that allows for a Equipment (CPE) can have a balanced security policy that allows for a
mostly end-to-end connectivity while keeping the major threats mostly end-to-end connectivity while keeping the major threats
outside of the home. It is based on an actual IPv6 deployment by outside of the home. It is documenting an existing IPv6 deployment
Swisscom and allows all packets inbound/outbound EXCEPT for some by Swisscom and allows all packets inbound/outbound EXCEPT for some
layer-4 ports where attacks and vulnerabilities (such as weak layer-4 ports where attacks and vulnerabilities (such as weak
passwords) are well-known. The blocked inbound ports is expected to passwords) are well-known. The policy is a proposed set of rules
be updated as threats come and go. 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014. This Internet-Draft will expire on June 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Rules for Balanced Security Policy . . . . . . . . . . . 3 3.1. Rules for Balanced Security Policy . . . . . . . . . . . 4
3.2. Rules example for Layer-4 Protection as Used by Swisscom 4 3.2. Rules Example for Layer-4 Protection: Swisscom
Implementation . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Informative References . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Internet access in residential IPv4 deployments generally consists of Internet access in residential IPv4 deployments generally consists of
a single IPv4 address provided by the service provider for each home. a single IPv4 address provided by the service provider for each home.
Residential CPE then translates the single address into multiple The residential CPE then translates the single address into multiple
private IPv4 addresses allowing more than one device in the home, but private IPv4 addresses allowing more than one device in the home, but
at the cost of losing end-to-end reachability. IPv6 allows all at the cost of losing end-to-end reachability. IPv6 allows all
devices to have a unique, global, IP address, restoring end-to-end devices to have a globally unique IP address, restoring end-to-end
reachability directly between any device. Such reachability is very reachability directly between any device. Such reachability is very
powerful for ubiquitous global connectivity, and is often heralded as powerful for ubiquitous global connectivity, and is often heralded as
one of the significant advantages to IPv6 over IPv4. Despite this, one of the significant advantages to IPv6 over IPv4. Despite this,
concern about exposure to inbound packets from the IPv6 Internet concern about exposure to inbound packets from the IPv6 Internet
(which would otherwise be dropped by the address translation function (which would otherwise be dropped by the address translation function
if they had been sent from the IPv4 Internet) remain. This document if they had been sent from the IPv4 Internet) remain.
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 This difference in residential default internet protection between
Service Provider CPE or for mobile Service Providers (where it can be IPv4 and IPv6 is a major concern to a sizable number of ISPs and the
centrally implemented). security policy described in this document addresses this concern
without damaging IPv6 end-to-end connectivity.
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 [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.
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).
2. Threats 2. Threats
For a typical residential network connected to the Internet over a For a typical residential network connected to the Internet over a
broadband or mobile connection, the threats can be classified into: broadband or mobile connection, the threats can be classified into:
o denial of service by packet flooding: overwhelming either the o denial of service by packet flooding: overwhelming either the
access bandwidth or the bandwidth of a slower link in the access bandwidth or the bandwidth of a slower link in the
residential network (like a slow home automation network) or the residential network (like a slow home automation network) or the
CPU power of a slow IPv6 host (like networked thermostat or any CPU power of a slow IPv6 host (like networked thermostat or any
skipping to change at page 3, line 32 skipping to change at page 3, line 45
from the Internet to an ink jet printer until the ink cartridge is from the Internet to an ink jet printer until the ink cartridge is
empty or like filing some file server with junk data; empty or like filing some file server with junk data;
o unauthorized use of services: like accessing a webcam or a file o unauthorized use of services: like accessing a webcam or a file
server which are open to anonymous access within the residential server which are open to anonymous access within the residential
network but should not be accessed from outside of the home network but should not be accessed from outside of the home
network or accessing to remote desktop or SSH with weak password network or accessing to remote desktop or SSH with weak password
protection; protection;
o exploiting a vulnerability in the host in order to get access to 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 data or to execute some arbitrary code in the attacked host;
as several against old versions of Windows;
o trojanized host (belonging to a Botnet) can communicate via a o trojanized host (belonging to a Botnet) can communicate via a
covert channel to its master and launch attacks to Internet covert channel to its master and launch attacks to Internet
targets. targets.
3. Overview 3. Overview
The basic goal is to provide a pre-defined security policy which aims 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 to block known harmful traffic and allow the rest, restoring as much
of end-to-end communication as possible. This pre-defined policy can of end-to-end communication as possible. This pre-defined policy
be centrally updated and could also be a member of a security policy should be centrally updated, as threats are changing over time. It
menu for the subscriber. 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 [RFC6092] and a "strict security" policy denying
access to all unexpected input packets.
3.1. Rules for Balanced Security Policy 3.1. Rules for Balanced Security Policy
These are an example set of generic rules to be applied. Each would 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 normally be configurable, either by the user directly or on behalf of
the user by a subscription service. This document does not address the user by a subscription service. This document does not address
the statefulness of the filtering rules as its main objective is to the statefulness of the filtering rules as its main objective is to
present an approach where some protocols (identified by layer-4 present an approach where some protocols (identified by layer-4
ports) are assumed weak or malevolent and therefore are blocked while ports) are assumed weak or malevolent and therefore are blocked while
all other protocols are assumed benevolent and are permitted. all other protocols are assumed benevolent and are permitted.
skipping to change at page 4, line 18 skipping to change at page 4, line 33
If we name all nodes on the residential side of the CPE as 'inside' 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 and all nodes on the Internet as 'outside', and any packet sent from
outside to inside as being 'inbound' and 'outbound' in the other outside to inside as being 'inbound' and 'outbound' in the other
direction, then the behavior of the CPE is described by a small set direction, then the behavior of the CPE is described by a small set
or rules: or rules:
1. Rule RejectBogon: apply ingress filtering in both directions per 1. Rule RejectBogon: apply ingress filtering in both directions per
[RFC3704] and [RFC2827] for example with unicast reverse path [RFC3704] and [RFC2827] for example with unicast reverse path
forwarding (uRPF) checks (anti-spoofing) for all inbound and forwarding (uRPF) checks (anti-spoofing) for all inbound and
outbound traffic (implicitly blocking link-local and ULA in the outbound traffic (implicitly blocking link-local and ULA in the
same shot), this is basically the Section 2.1 Basic Sanitation same shot), as described in Section 2.1 Basic Sanitation and
and Section 3.1 Stateless Filters of [RFC6092]; Section 3.1 Stateless Filters of [RFC6092];
2. Rule AllowManagement: if the CPE is managed by the SP, then allow 2. Rule AllowManagement: if the CPE is managed by the SP, then allow
the management protocols (SSH, SNMP, syslog, IPfix, ...) from/to the management protocols (SSH, SNMP, syslog, TR-069, IPfix, ...)
the SP Network Operation Center if the management is not done by from/to the SP Network Operation Center;
non-IP techniques such as the Broadband Forum TR-69;
3. Rule ProtectWeakServices: drop all inbound and outbound packets 3. Rule ProtectWeakServices: drop all inbound and outbound packets
whose layer-4 destination is part of a limited set (see whose layer-4 destination is part of a limited set (see
Section 3.2), the intent is to protect against the most common Section 3.2), the intent is to protect against the most common
unauthorized access and avoid propagation of worms (even if the unauthorized access and avoid propagation of worms; an advanced
latter is questionable in IPv6); an advanced residential user residential user should be able to modify this pre-defined list;
should be able to modify this pre-defined list;
4. Rule Openess: allow all unsolicited inbound packets with rate 4. Rule Openess: allow all unsolicited inbound packets with rate
limiting the initial packet of a new connection (such as TCP SYN, limiting the initial packet of a new connection (such as TCP SYN,
SCTP INIT or DCCP-request not applicable to UDP) to provide very SCTP INIT or DCCP-request, not applicable to UDP) to provide very
basic protection against SYN port and address scanning attacks. basic protection against SYN port and address scanning attacks.
All transport protocols and all non-deprecated extension headers All transport protocols and all non-deprecated extension headers
are accepted. This is a the major deviation from REC-11, REC-17 are accepted. This is a the major deviation from REC-11, REC-17
and REC-33 of [RFC6092]. and REC-33 of [RFC6092].
5. All requirements of [RFC6092] except REC-11, REC-18 and REC-33 5. All requirements of [RFC6092] except REC-11, REC-18 and REC-33
must be supported. must be supported.
3.2. Rules example for Layer-4 Protection as Used by Swisscom 3.2. Rules Example for Layer-4 Protection: Swisscom Implementation
As an example only, the rule ProtectWeakService was implemented by As of 2013, Swisscom has implemented the rule ProtectWeakService as
Swisscom in 2013: 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.
+-----------+------+-----------------------------------+ +-----------+------+-----------------------------------+
| Transport | Port | Description | | Transport | Port | Description |
+-----------+------+-----------------------------------+ +-----------+------+-----------------------------------+
| tcp | 22 | Secure Shell (SSH) | | tcp | 22 | Secure Shell (SSH) |
| tcp | 23 | Telnet | | tcp | 23 | Telnet |
| tcp | 80 | HTTP | | tcp | 80 | HTTP |
| tcp | 3389 | Microsoft Remote Desktop Protocol | | tcp | 3389 | Microsoft Remote Desktop Protocol |
| tcp | 5900 | VNC remote desktop protocol | | tcp | 5900 | VNC remote desktop protocol |
+-----------+------+-----------------------------------+ +-----------+------+-----------------------------------+
skipping to change at page 5, line 34 skipping to change at page 6, line 8
| tcp | 631 | Internet Printing Protocol | | tcp | 631 | Internet Printing Protocol |
| udp | 1900 | Simple Service Discovery Protocol | | udp | 1900 | Simple Service Discovery Protocol |
| tcp | 2869 | Simple Service Discovery Protocol | | tcp | 2869 | Simple Service Discovery Protocol |
| udp | 3702 | Web Services Dynamic Discovery | | udp | 3702 | Web Services Dynamic Discovery |
| udp | 5353 | Multicast DNS | | udp | 5353 | Multicast DNS |
| udp | 5355 | Link-Lcl Mcast Name Resolution | | udp | 5355 | Link-Lcl Mcast Name Resolution |
+-----------+------+-----------------------------------+ +-----------+------+-----------------------------------+
Table 2: Drop Inbound and Outbound Table 2: Drop Inbound and Outbound
These example lists will probably evolve with the time as new Choosing services to protect is not an easy task, and as of 2013
protocols and new threats appear. The update of the specific rules there is no public service proposing a list of ports to use in such a
could be done by firmware upgrade, policy update (for example by policy. The Swisscom approach was to think in terms of services, by
Broadband Forum TR-69). 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.
[DSHIELD] was used by Swisscom to set-up those filters. Another The process used to set-up and later update the filters is out of
source of information could be the appendix A of [TR124]. The above scope of this document. The update of the specific rules could be
example does not block GRE tunnels ([RFC2473]) so this is a deviation done together with a firmware upgrade or by a policy update (for
from [RFC6092]. example using Broadband Forum TR-069).
Note: the authors believe that with this set the usual residential Among other sources, [DSHIELD] was used by Swisscom to set-up their
subscriber, the proverbial grand-ma, is protected. Of course, filters. Another source of information could be the appendix A of
technical susbcribers should be able to open other applications [TR124]. The L4-filter as described does not block GRE tunnels
(identified by their layer-4 ports or IP protocol numbers) through ([RFC2473]) so this is a deviation from [RFC6092].
their CPE through some kind of user interface or even select a
completely different security policy such as the open or 'closed' Note: the authors believe that with a dozen of rules only, a naive
policies defined by [RFC6092]. 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 [RFC6092]. This is the case in the
Swisscom deployment.
It is worth mentioning that PCP ([RFC6887]), UPnP ([IGD]) and similar
protocols can also be used to dynamically override the default rules.
4. IANA Considerations 4. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
5. Security Considerations 5. Security Considerations
The authors of the documents believe and the Swisscom deployment The security policy protects from the following type of attacks:
shows that the following attack are mostly stopped:
o Unauthorized access because vulnerable ports are blocked o Unauthorized access because vulnerable ports are blocked
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.
To the authors' knowledge, there has not been any incident related to
this deployment in Swisscom network, and no customer complaints have
been registered.
This set of rules cannot help with the following attacks: This set of rules cannot help with the following attacks:
o Flooding of the CPE access link; o Flooding of the CPE access link;
o Malware which is fetched by inside hosts on a hostile web site o Malware which is fetched by inside hosts on a hostile web site
(which is in 2013 the majority of infection sources). (which is in 2013 the majority of infection sources).
6. Acknowledgements 6. Acknowledgements
The authors would like to thank several people who initiated the The authors would like to thank several people who initiated the
discussion on the ipv6-ops@lists.cluenet.de mailing list and others discussion on the ipv6-ops@lists.cluenet.de mailing list and others
who provided us valuable feedback and comments, notably: Tore who provided us valuable feedback and comments, notably: Tore
Anderson, Rajiv Asati, Lorenzo Colitti, Merike Kaeo, Simon Leinen, Anderson, Rajiv Asati, Fred Baker, Lorenzo Colitti, Paul Hoffman,
Eduard Metz, Martin Millnert, Benedikt Stockebrand. Thanks as well Merike Kaeo, Simon Leinen, Eduard Metz, Martin Millnert, Benedikt
to the following SP that discussed with the authors about this Stockebrand. Thanks as well to the following SP that discussed with
technique: Altibox, Swisscom and Telenor. the authors about this technique: Altibox, Swisscom and Telenor.
7. Informative References 7. Informative References
[DSHIELD] DShield, "Port report: DShield", , <https:// [DSHIELD] DShield, "Port report: DShield", <https://
secure.dshield.org/portreport.html?sort=records>. secure.dshield.org/portreport.html?sort=records>.
[IGD] UPnP Forum, "WANIPConnection:2 Service", December 20110,
<http://upnp.org/specs/gw/UPnP-gw-
WANIPConnection-v2-Service.pdf>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January Residential IPv6 Internet Service", RFC 6092, January
2011. 2011.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
[TR124] Broadband Forum, "Functional Requirements for Broadband [TR124] Broadband Forum, "Functional Requirements for Broadband
Residential Gateway Devices", December 2006, <http://www Residential Gateway Devices", December 2006, <http://www
.broadband-forum.org/technical/download/TR-124.pdf>. .broadband-forum.org/technical/download/TR-124.pdf>.
Authors' Addresses Authors' Addresses
Martin Gysi Martin Gysi
Swisscom Swisscom
Binzring 17
Zuerich 8045
Switzerland Switzerland
Phone: +41 58 223 57 24
Email: Martin.Gysi@swisscom.com Email: Martin.Gysi@swisscom.com
Guillaume Leclanche Guillaume Leclanche
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec, QC G1R 2E1 Quebec, QC G1R 2E1
Canada Canada
Phone: +1 418 656 9254 Phone: +1 418 656 9254
Email: guillaume.leclanche@viagenie.ca Email: guillaume.leclanche@viagenie.ca
skipping to change at page 7, line 37 skipping to change at page 9, line 4
Email: guillaume.leclanche@viagenie.ca Email: guillaume.leclanche@viagenie.ca
Eric Vyncke (editor) Eric Vyncke (editor)
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2 778 4677 Phone: +32 2 778 4677
Email: evyncke@cisco.com Email: evyncke@cisco.com
Ragnar Anfinsen Ragnar Anfinsen
Altibox Altibox
Breiflaatveien 18
Stavanger 4069
Norway Norway
Phone: +47 93488235
Email: Ragnar.Anfinsen@altibox.no Email: Ragnar.Anfinsen@altibox.no
 End of changes. 35 change blocks. 
67 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/