Network Working Group M. Baugher
Internet-Draft Cisco
Intended status: Standards Track E. Nedellec
Expires: September 9, 2009 Orange Labs
M. Saaranen
Nokia
B. Stark
AT&T
March 8, 2009
IPv6 Services for UPnP Residential Networks
draft-bnss-v6ops-upnp-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Baugher, et al. Expires September 9, 2009 [Page 1]
Internet-Draft v6HomeServices March 2009
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Baugher, et al. Expires September 9, 2009 [Page 2]
Internet-Draft v6HomeServices March 2009
Abstract
This paper considers some IPv6 issues for residential networks,
including address scoping and firewalls. The paper describes IPv6
usage in the UPnP Forums's Device Architecture standard; some
clarifications and changes are considered. The paper seeks comments
on IPv6 address usage, address selection, and the need to develop
best practices for IPv6 firewall traversal.
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. UPnP and the UPnP Forum . . . . . . . . . . . . . . . . . 4
1.2. UPnP on IPv6 . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. UPnP Security . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Goals of This Document . . . . . . . . . . . . . . . . . . 5
1.5. Overview of This Document . . . . . . . . . . . . . . . . 5
1.6. Conformance Language . . . . . . . . . . . . . . . . . . . 6
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Private Network Addressability . . . . . . . . . . . . . . 7
2.2. Outside-In Access . . . . . . . . . . . . . . . . . . . . 8
2.3. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Cross-Site Services . . . . . . . . . . . . . . . . . . . 9
3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Addressing Issues . . . . . . . . . . . . . . . . . . . . 10
3.2. Firewall Issues . . . . . . . . . . . . . . . . . . . . . 10
3.3. Issues List . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Routed private networks . . . . . . . . . . . . . . . 11
3.3.2. Remote access . . . . . . . . . . . . . . . . . . . . 11
3.3.3. Site to site access . . . . . . . . . . . . . . . . . 11
3.3.4. Firewall control . . . . . . . . . . . . . . . . . . . 11
4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Routed Private Networks . . . . . . . . . . . . . . . . . 12
4.2. Remote Access Addressing . . . . . . . . . . . . . . . . . 12
4.3. Firewall Control . . . . . . . . . . . . . . . . . . . . . 13
4.4. Site to Site Access . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Assets, Risks and Threats . . . . . . . . . . . . . . . . 14
5.2. Authentication and Authorization . . . . . . . . . . . . . 14
5.3. Problems with Password-based Authentication . . . . . . . 15
5.4. Authenticated Firewall Access . . . . . . . . . . . . . . 15
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Baugher, et al. Expires September 9, 2009 [Page 3]
Internet-Draft v6HomeServices March 2009
1. Background
This paper considers IPv6 usage in the UPnP(TM) Device Architecture
(UDA) [UDA1.1]. Three IPv6 issues for the UDA are described below.
Briefly stated, the latest revision of the UPnP Device Architecture
deprecates Site-Local Unicast Addresses in accordance with the
evolving IPv6 standard [RFC4291] and replaces it with global
addresses; the UDA needs to recommend proper usage of IPv6 Unique
Local Unicast Addresses (ULA) and Global Unicast Addresses (GUA) in
UPnP Site-Local Multicast announcements. Second, new services such
as remote access can potentially use alternative IPv6 address types
such as ULA or GUA, and the best choices need to be determined.
Third, UPnP IPv6 usage is affected by IPv6 firewall policy. The
paper focuses on these three IPv6 usage and support issues.
UPnP IPv6 usage and support become more important as dual-stack UPnP
devices become more common. A variety of UPnP Device Control
Protocols (DCPs) are shipped in tens of millions of devices
throughout the world. UPnP DCPs can therefore greatly affect the
worldwide deployment of IPv6. This section gives background on UPnP
and then describes the goals of the present work.
1.1. UPnP and the UPnP Forum
The UPnP Forum is an industry consortium of companies whose engineers
create interoperable standards for PCs, TVs, network storage, and
other electronic devices. These standards are for both fixed-
location and mobile devices that operate on private networks. Future
remote access services, moreover, will operate over the public
Internet to securely connect a remote device to a private network
[UPnPWC]. UPnP protocols perform device discovery, service
description, service control, eventing, and presentation
[UDA1.1][UDA1.0] for audio/video, automation and network gateway
services, to name a few. The UPnP Internet Gateway Device (IGD) DCP,
for example, defines an IPv4 network address translation (NAT)
traversal service that is found in most residential IPv4 NATs
[UPnPIGD].
The UPnP Device Architecture (UDA) is an ISO/IEC standard (ISO/IEC
29341) that can run over IPv4 or IPv4/IPv6 dual stack. UDA 1.1 is
the latest version and is a backward-compatible extension to UDA 1.0.
Both versions support a "two-box" configuration of a controlled
device ("device") that accepts actions from a controlling device,
called a "control point" ("CP"). UPnP also supports a "three-box"
configuration where a CP can control one device on behalf of another
device. The three-box configuration is used in the UPnP Audio/Video
Architecture, for example, where a CP controls A/V sessions between a
media server and a renderer [UPnPAV].
Baugher, et al. Expires September 9, 2009 [Page 4]
Internet-Draft v6HomeServices March 2009
1.2. UPnP on IPv6
The UPnP Forum does not specify IPv6 customer premises equipment
(CPE) such as cable or DSL modems and refers to other standards
organizations for the definition of IPv6 and other basic networking
services[BBF][Cable][SW][W]. The UPnP Forum specifies "control
interfaces" to IPv4 and dual-stack devices on private networks, such
as residential networks that have Wi-Fi and Ethernet local area
networks. The UPnP protocol standard today supports IPv6 "dual
stack" operation, but IPv4 is mandatory in the UPnP Device
Architecture (UDA). Thus, a UPnP device that announces its services
and provides them over IPv6 will simultaneously do so over IPv4 as
well. Dual stack operation is transparent to UPnP applications
except for address selection and usage.
For IPv4, the UPnP discovery protocol, "Simple Service Discovery
Protocol," (SSDP) uses an administratively-scoped multicast address
assigned by IANA to UPnP; in UDA 1.1, eventing uses a second, IANA
administratively-scoped multicast address[IANAIPv4]. For UPnP dual
stack operation, IANA reserves IPv6 link-local and variable scope
multicast addresses for UPnP[IANAIPv6].
1.3. UPnP Security
Authenticated services are rare on residential networks today. More
often than not, the owner of an "unmanaged residential network"
[RFC3750] does not know how to configure it. This applies to access
controls as well, which are often not used by people who really need
them. This is despite the fact that the UPnP Device Security
specification was published several years ago to overlay
authorization and authentication on UPnP services. The lack of such
security resulted in some well-publicized attacks on UPnP devices in
recent years [Hemel][FlashAttack]. These attacks can be prevented by
effective access controls for services, including IPv6 firewall
interfaces.
1.4. Goals of This Document
This paper seeks comments from the IETF on private-network
application of IETF IPv6 standards, notably the use of scoped unicast
addressing [RFC5220][RFC4193][RFC4007][RFC4291] and the need to
establish best practices for IPv6 firewalls and interfaces.
1.5. Overview of This Document
Section 2 considers some requirements for UPnP "dual stack" operation
and IPv6 services. Section 3 describes the UPnP "dual stack" issues.
Section 4 proposes solutions. Section 5 is Security Considerations,
Baugher, et al. Expires September 9, 2009 [Page 5]
Internet-Draft v6HomeServices March 2009
and section 6 gives the Summary.
1.6. Conformance Language
There is no normative language used in this paper, which is
informative only.
Baugher, et al. Expires September 9, 2009 [Page 6]
Internet-Draft v6HomeServices March 2009
2. Requirements
Many of the requirements that are described here for UPnP are generic
to residential networks and to many types of private networks. The
focus of this paper is UPnP, however, so no attempt is made to survey
the differences with Bonjour, sensor networks, various home
automation protocols, or other systems that share some requirements
with UPnP but which are nonetheless different protocols. Our
requirements are for UPnP dual-stack operation and are listed in the
following sub-sections. This is not a complete list since most
requirements are satisfied by existing IPv6 standards. Rather, the
following are requirements that might have different potential
solutions given existing standards and practices.
2.1. Private Network Addressability
Most residential networks today consist of a single local area
network or a few LANs that are bridged to share a common,
administratively-scoped IPv4 address space. Many believe that this
is the way it should be and advocate that a single-subnet
configuration should be a best practice for small, private networks
like residential networks. In IPv6 terms, this would mean that
multiple wired and wireless interfaces on the gateway/router would be
reachable using link-local scope, which is the only scope that is
mandated in the UPnP Device Architecture [UDA1.1][UDA1.0].
Conversely, if the gateway/router managed the multiple network
interfaces as distinct sub-networks (links), UPnP messages sent to
link-local scope would be confined to a single sub-network and not
reach the entire residential network. Vendors and service providers
are aware of the connectivity problems that occur when IPv4 network
devices are misconfigured to support "nested NATs" resulting in
multiple subnets in the home. In the case of IPv4, there is no
remedy but to re-configure the residential network. This level of
management is beyond what most home users are willing or able to
perform, but proper configuration is needed for full connectivity
within the residential network. For example, users may want an
Ethernet-connected printer to interoperate with a personal computer
on the Wi-Fi network.
Traffic that is wholly within the residential network is uncommon
today. Published studies have shown that Wi-Fi, Ethernet and other
networks in U.S. homes generally provide only Internet access to
personal computers. With the possible exception of printing, there
is little or no intra-network traffic, and people routinely use email
or web sites to transfer files between computers in the home. The
problems of multiple subnetworks or "nested NATs" are not all that
apparent for Internet access from inside the home. There is a
definite trend in new products, however, to support intra-network
Baugher, et al. Expires September 9, 2009 [Page 7]
Internet-Draft v6HomeServices March 2009
transfers such as to network attached storage and for media streaming
within the residence. These applications are common among early
adopters.
The authors are not aware of any compelling need today for UPnP home
networks to be routed rather than bridged. There might be a future
need for connecting local and personal area networks that use 64-bit
Medium Access Control addressing [RFC4944], however, and protocols
that accommodate a variety of network types, topologies and equipment
are highly desirable. For this reason, it is taken as a requirement
to support routed residential networks.
2.2. Outside-In Access
There are emerging applications that connect a mobile device across
the public Internet to a device on a private network, such as to a
network attached storage device in the residence. IPv4 applications
support this today using such means as Dynamic DNS coupled with a NAT
port mapping from a public IPv4 address to an administratively-scoped
address on the residential network. UPnP has an IPv4 NAT traversal
service that has the side-effect of allowing forwarding through a
residential firewall [UPnPIGD]. A similar capability is needed for
IPv6. To match the IPv4 service, IPv6 residential gateways need to
support "outside-in" access from the public Internet to a private
network.
2.3. Firewall
This paper assumes that residential gateways will initially deploy
IPv6 firewalls that functionally match IPv4 firewalls. For
outside-in access, this functionality filters tuples of addresses and
upper-layer protocol values from the IPv6 headers [W] [NSA]. For
outside-in (i.e. "inbound") traffic, this means that "...The general
operating principle is that transport layer traffic is only permitted
into the interior network of a residential IPv6 gateway when it has
been solicited explicitly by interior nodes" [W].
Thus, if the residential gateway hosts an IPv6 firewall, then a
firewall traversal method is needed by residential network
applications to permit external devices to connect to them for so-
called "outside-in" access. Unauthenticated IPv4 NAT traversal is
common today: There are typically no access controls used for dynamic
IPv4 NAT traversal. Should this practice be continued in IPv6? An
authoritative best practices standard for firewalls is needed to
answer this question. As a start, this paper takes as a requirement
that four alternative configurations need to be supported for most
residential-network firewalls.
Baugher, et al. Expires September 9, 2009 [Page 8]
Internet-Draft v6HomeServices March 2009
1. Firewall allows all unsolicited traffic through to any device on
the residential network
2. Firewall blocks unsolicited traffic and any application can open
pinholes
3. Firewall blocks unsolicited traffic and only authorized
applications can connect (or open a pinhole)
4. Firewall blocks unsolicited traffic and no outside application
can connect (or inside application can open a pinhole)
The Security Considerations of section 5 considers attacks where the
first two configurations are practically identical in terms of risk.
The third configuration requires a method for strongly identifying,
authorizing, and authenticating users and their devices. The third
configuration has different solutions such as "authenticated firewall
traversal" using an authenticated VPN connection [W], or
"authenticated firewall control" by which an application on the
inside is authorized and authenticated to open forwarding to its IPv6
transport address.
Another type of remote access allows common services to operate over
multiple private networks and is described next.
2.4. Cross-Site Services
Remote Access services can be much more ambitious than simply
connecting a single device to some other device on the residential
network: Commercial products today can permanently interconnect
multiple devices on two or more residential networks, such as for
"wellness" monitoring of remote family members or for sharing a media
library. In this case, a device on one private network is authorized
to share designated services that are hosted on another private
network. Whereas "outside-in" access is typically session-based
access, cross-site services are permanent.
Baugher, et al. Expires September 9, 2009 [Page 9]
Internet-Draft v6HomeServices March 2009
3. Issues
There are two classes of issues. The first concerns use of IPv6
link-local, site-local, unique-local and global addresses. The
second concerns firewall policy. Each are discussed in a separate
section below and followed by a summary "Issues List".
3.1. Addressing Issues
UPnP operation on IPv6 has been changed between the two versions of
the UPnP Device Architecture (UDA). The principal change is in IPv6
address usage. UDA 1.0 mandates the use of Link-Local Unicast
Addresses and allows use of Site-Local Unicast addresses; UDA 1.0
uses link-local and site-local multicast for its service discovery.
UDA 1.1 dropped Site-Local Unicast Addresses in accordance with the
standard [RFC3879] [RFC4291] but did not adopt Unique Local Unicast
Addressing (ULA); this is an issue for routed local networks because
link local addressing only works on a single subnetwork (link).
Moreover, the UDA 1.1 IPv6 specification uses "global address" in
place of Site-Local Unicast Address, which might imply that a global
address allocation is needed for operation on a private network. A
second issue is in the practical use of ULA and GUA in address
selection [RFC5220][RFC3484]. When does the UPnP application choose
to use ULA or GUA in a multicast announcement? UPnP address-scoping
policy and dual-stack address selection usage may need to be
clarified.
3.2. Firewall Issues
As discussed in the Requirements Section above, with an IPv6 firewall
comes the need to allow some remote senders to connect from the
outside to certain devices on the residential network. Section 2.3
describes the need to support authenticated access as one of several
configuration options. This concerns network security policy and is
considered in some detail in section 5, Security Considerations.
Authenticated firewall access presents a problem for firewall vendors
who need to offer a consistent level of security across multiple
types of firewall interfaces such as UPnP and Bonjour, for example.
Perhaps the ideal solution would be for the industry to have one
interface for IPv6 firewalls. It is likely that multiple protocols
for firewall traversal or firewall control might be needed by the
different applications that use them. If convergence to a single
protocol proves unrealistic, convergence to a set of best practices
might be very helpful.
Baugher, et al. Expires September 9, 2009 [Page 10]
Internet-Draft v6HomeServices March 2009
3.3. Issues List
One issue described below stems from the need to define an IPv6
"site" as opposed to a "link" when the private network is routed
across multiple subnetworks. A second issue is how to reach a site
using IPv6, usually over an IPv4 tunnel. Another issue concerns
offering application services over multiple private networks. Yet
another issue is IPv6 firewall access. These are discussed below.
3.3.1. Routed private networks
UDA 1.1 mandates use of IPv6 link-local addressing and allows use of
site-local multicast for UPnP service discovery but does not specify
use of IPv6 Unique Local Unicast Addressing, which is needed for
routed residential networks.
3.3.2. Remote access
A remote device can today use IPv4 addressing and Dynamic DNS to
access a local network device; the local device uses a UPnP NAT
traversal service. A remote IPv6 device can do the same, but the
local IPv6 network needs an outside-in access method when there is an
IPv6 firewall.
3.3.3. Site to site access
Local and remote IPv6 device can use global unicast IPv6 addresses
for a single session. But what is the correct addressing model for a
more permanent connection among multiple devices on two or more
private networks?
3.3.4. Firewall control
A firewall vendor will need to support a consistent level of service
across one or more firewall interfaces, and authenticated access is
needed in the firewall.
Baugher, et al. Expires September 9, 2009 [Page 11]
Internet-Draft v6HomeServices March 2009
4. Solution Space
To each of the issues listed above, one or more proposed solutions
are given in this section.
4.1. Routed Private Networks
The authors assume that Unique Local IPv6 Unicast Addresses[RFC4193]
are the successor to deprecated Site-Local Unicast Addresses
[RFC3879][RFC4862]. RFC 3879 explains that a "site" is typically not
well-defined. Specifically, sites can overlap; when this happens,
unicast site-local addresses can collide. A Unique Local Unicast
Address (ULA) contains a 40-bit random number that has a very low
probability of colliding.
The motivation for using ULA is of course not security but simplicity
of packet forwarding and filtering on a residential network that has
multiple subnetworks.
Thus, ULA is preferable to "global addresses" for bridged and routed
residential networks - provided a ULA prefix can be properly
obtained. Dual stack Devices that comply with UDA 1.1, however, will
continue to advertise "global addresses" (GUA) in site-scoped Simple
Service Discovery Protocol (SSDP) announcements. UDA 1.0 Devices
will advertise Site-Local Unicast Addresses. Dual stack devices on
the market today are more likely to support Site-Local Unicast
Addresses rather than ULA and so backward-compatibility is essential.
A UDA 1.1 Control Point (CP) will accept a site-local unicast in a
site-scope SSDP announcement, for backward compatibility, but a UDA
1.1 Device will send only a GUA in a site-scope SSDP announcement.
Any backward-compatible revision of UDA 1.1 IPv6 usage, therefore,
would require CPs to accept site-local unicast or a GUA in SSDP
announcements, but a Device would send ULA, if one is available. If
a ULA prefix cannot be acquired on the local network, then GUA would
be preferred. IPv6 Address selection logic [RFC3484] thus needs to
be specialized for UPnP.
4.2. Remote Access Addressing
The proposed addressing mode is Global Unicast Addresses (GUA) for
session-based remote access of a single device into a home network.
Since this type of UPnP remote access is performed on a transient,
session basis, any needed firewall signaling can be performed at
session-establishment time.
Baugher, et al. Expires September 9, 2009 [Page 12]
Internet-Draft v6HomeServices March 2009
4.3. Firewall Control
One compelling solution for IPv6 firewall control is to leave it to
the vendors who offer an IPv4 NAT traversal service (e.g. UPnP,
Bonjour). This solution is compelling because it is inevitable and
already happening in the industry. The industry would likely
benefit, however, from a published consensus on best practices for
stateless and stateful packet filtering [W] [NSA]. Authenticated
firewall access and related issues are discussed below in section 5,
Security Considerations.
4.4. Site to Site Access
ULA is one solution for offering and requesting services across two
or more private networks. ULA seems to be a good choice for
extending services across private networks in a static and
transparent manner. Such transparency would be defeated by the need
for explicit firewall signaling for each session across the private
networks. How sites interconnect to form a single address scope for
common services needs to be defined.
Baugher, et al. Expires September 9, 2009 [Page 13]
Internet-Draft v6HomeServices March 2009
5. Security Considerations
This paper considers IPv6 address usage and IPv6 firewall policy.
The security considerations of IPv6 addressing are relatively small;
RFC 3484 describes an attack on host privacy in which an end system
is forced to reveal its own source addresses [RFC3484]. The security
considerations of IPv6 firewall control, however, are not so small.
A firewall is a residential-network "asset" that depends on
residential network security, which is described next.
5.1. Assets, Risks and Threats
Residential networks have critical assets such as gateway devices,
personal computers, firewalls and network storage. Among the biggest
risks to these assets are the re-configuration of network devices and
theft of personal passwords. By re-configuring the DNS server name,
for example, an attacker can do a pharming attack. A phishing attack
steals passwords to get access to online banking accounts and
password-protected devices. Malware is a well-known attack vector
for pharming and phishing attacks [FlashAttack]. Computer viruses,
trojan horses and other types of malware get routinely downloaded and
installed on programmable devices in the residential network.
Another attack vector is "war driving", which typically uses an open
wireless LAN to gain access to a residential network device. An IPv6
firewall asset is therefore subject to these risks and threats.
5.2. Authentication and Authorization
Strong identification, authentication and authorization can prevent
threats to residential networks from war drivers, visitors, and other
interlopers who gain access through an open wireless LAN or other
means. Also, malware can gain execution privileges on an authorized
end system, such as a personal computer that can set the DNS name in
a residential gateway. Thus, automated methods of authentication
using public-key or secret key cryptography are sometimes
insufficient. In the case of malware, multi-factor authentication
such as device public-key authentication coupled with a user
passphrase puts the user in the loop. Multi-factor authentication
can potentially prevent malware from executing its actions on the
host device. But there are human-factors problems when the user is
in the authorization loop: The user might be conditioned to approve
every action and type in a password whenever prompted to do so, for
example. As discussed below, password-based authentication comes
with additional risks.
Baugher, et al. Expires September 9, 2009 [Page 14]
Internet-Draft v6HomeServices March 2009
5.3. Problems with Password-based Authentication
In general, passwords are a poor authentication method for IPv4 and
dual-stack residential networks; this has been true for some time
[Neumann][RT79]. And it is truer today given advances in hardware
speeds and password cracking [Elcomsoft]. It is possible that
advances in password security engineering can improve how people use
passwords in an unmanged environment such as the home [Anderson].
Practically speaking, there is no proven, simple method to ensure
that passwords are strong and unique across unmanaged residential-
network devices. Use of identical and similar passwords for a
variety of purposes such as for firewall control and online banking,
increases the risks of password compromise. A combination of
techniques such as public-key cryptography, passwords with password
checkers, strong pre-shared symmetric keys, hardware token devices
and other means are referenced in current standards [WPS] [UDS1.0].
These methods potentially apply to firewall access control as well.
5.4. Authenticated Firewall Access
Not all users of residential networks need or want security services.
Many prefer to run open-wireless networks and some leave their
firewalls turned off to enable convenient access to their residential
network devices. The norm for residential gateway device vendors,
however, is to ship their products with a firewall enabled. Thus,
people who don't want security often need to use some form of
authenticated access to disable it.
If by default, the firewall drops unsolicited external traffic but
allows any internal device to open it to unsolicited traffic, then
there is some question as to value of the firewall. Malware and war
drivers will be able to open the firewall to their internal addresses
- and in some cases to any address of their choosing. Thus,
authenticated access is a reasonable default for an IPv6 firewall
interface, but the application needs proper authentication. If the
personal computer that controls the firewall is infected by malware,
proper authentication might require user input or other methods.
Authentication and authorization are hard problems in un-managed
networks. A one-time procedure is usually needed for a human user to
prove locality or control as a precondition for an authorization
[WE]. An initial authorization for a firewall control interface
might be an authorization for packet forwarding for an internal IPv6
GUA according to some filtering specification, for example. A more
privileged authorization might be to request packet forwarding for
another device, such as a visitor to the residential network.
Authorization levels as well as authentication methods need to be
considered as part of IPv6 best practices for firewalls.
Baugher, et al. Expires September 9, 2009 [Page 15]
Internet-Draft v6HomeServices March 2009
6. Summary
This paper defines a set of requirements for IPv6 applications, it
lists the issues in meeting these requirements, and it describes some
possible solutions. Section 4, Solution Space, describes solutions
and identifies several new problems for further work. IPv6 Unique
Local Unicast Addresses are a solution to site unicast addressing,
but how to apply ULA to cross-site services is left as an open
question in this paper. More practical experience is needed with
UPnP dual-stack operation to understand how well address selection
works for addressing scopes beyond link-local. For global access
through a firewall, authentication is a required option. Thus, best
practices for IPv6 firewalls would be very helpful to vendors and
service providers. This paper considers only "outside in" firewall
control. "Inside-out" firewalling is not properly considered in this
paper.
Baugher, et al. Expires September 9, 2009 [Page 16]
Internet-Draft v6HomeServices March 2009
7. Acknowledgements
The authors thank Jari Arkko, Fred Baker, Jean-Francois Cadiou, Ralph
Droms, Eric Vyncke, Bruce Fairman, Thomas Herbst, Alan Messer, Toby
Nixon, Dave Oran, Clarke Stevens, Tim Spets, Mark Townsley, Greg
White and Dan Wing.
Baugher, et al. Expires September 9, 2009 [Page 17]
Internet-Draft v6HomeServices March 2009
8. Informative References
[Anderson]
Anderson, R., "Security Engineering", 2001.
[BBF] Broadband Forum, "Functional Requirements for Broadband
Residential Gateway Devices", TR-124 (http://
www.broadband-forum.org/technical/download/TR-124.pdf)",
December 2006.
[Cable] Cable Labs, "IPv4 and IPv6 eRouter Specification (http://
www.cablelabs.com/specifications/
CM-SP-eRouter-I03-070518.pdf)", May 2007.
[Elcomsoft]
Elcomsoft, "ElcomSoft Breaks Wi-Fi Encryption Faster with
GPU Acceleration", October 2008.
[FlashAttack]
Gnu Citizen, "Flash UPnP Attack FAQ
(http://www.gnucitizen.org/blog/flash-upnp-attack-faq/)",
January 2008.
[Hemel] Hemel, A., "Universal Plug and Play: Dead simple or simply
deadly? (http://www.upnp-hacks.org/sane2006-paper.pdf)",
April 2006.
[IANAIPv4]
IANA, "IANA Multicast Address Assignment
(http://www.iana.org/assignments/multicast-addresses)",
January 2009.
[IANAIPv6]
http://www.iana.org/assignments/ipv6-multicast-addresses,
"IANA IPv6 Multicast Address Assignment", January 2009.
[NSA] Potyraj, C., "Firewall design considerations for IPv6,
NSA, Report #1733-041R-2007", October 2007.
[Neumann] Neumann, P., "Risks of Passwords
(http://portal.acm.org/citation.cfm?id=175289)",
April 1994.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Unmanaged Networks IPv6 Transition Scenarios",
Baugher, et al. Expires September 9, 2009 [Page 18]
Internet-Draft v6HomeServices March 2009
RFC 3750, April 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
[RT79] Morris, R. and K. Thompson, "Password Security: A Case
History", November 1979.
[SW] Singh, H. and W. Beebee, "IPv6 CPE Router Recommendations
(http://tools.ietf.org/html/
draft-wbeebee-ipv6-cpe-router-03)", October 2008.
[TR-064] http://www.broadband-forum.org/technical/download/
TR-064.pdf, "LAN-Side DSL CPE Configuration", May 2004.
[UDA1.0] UPnP Forum, "UPnP Device Architecture, Version 1.0 (http:/
/www.upnp.org/specs/arch/
UPnP-arch-DeviceArchitecture-v1.0.pdf)", 2008.
Baugher, et al. Expires September 9, 2009 [Page 19]
Internet-Draft v6HomeServices March 2009
[UDA1.1] UPnP Forum, "UPnP Device Architecture, Version 1.1 (http:/
/www.upnp.org/specs/arch/
UPnP-arch-DeviceArchitecture-v1.1.pdf)", 2008.
[UDS1.0] Ellison, C., "DeviceSecurity:1 (http://www.upnp.org/
standardizeddcps/documents/DeviceSecurity_1.0cc_001.pdf)",
November 2003.
[UPnPAV] UPnP Forum, "UPnP AV Architecture:1 (http://www.upnp.org/
specs/av/UPnP-av-AVArchitecture-v1.pdf)", September 2008.
[UPnPIGD] UPnP Forum, "UPnP Internet Gateway Device Standardized
Device Control Protocol V 1.0
(http://www.upnp.org/standardizeddcps/)", November 2001.
[UPnPWC] UPnP Forum, "UPnP Working Committees
(http://www.upnp.org/membership/committees.asp)",
February 2009.
[W] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment for Providing Residential IPv6
Internet Service,
(draft-ietf-v6ops-cpe-simple-security-03)", July 2008.
[WE] Wlaker, J. and C. Ellison, "UPnP[TM] Security Ceremonies
Design Document (www.upnp.org/download/standardizeddcps/
UPnPSecurityCeremonies_1_0secure.pdf)", October 2003.
[WPS] Wikipedia, "Wi-Fi Protected Setup
(http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup)",
February 2009.
Baugher, et al. Expires September 9, 2009 [Page 20]
Internet-Draft v6HomeServices March 2009
Authors' Addresses
Mark Baugher
Cisco
800 East Tasman Drive
San Jose, CA 95164
US
Phone: (503) 245-4543
Email: mbaugher@cisco.com
Erwan Nedellec
Orange Labs
4 rue du clos courtel
35510 Cesson-Sevigne,
France
Phone: +33 (0) 2 99 36 35 92
Email: erwan.nedellec@orange-ftgroup.com
Mika Saaranen
Nokia
Visiokatu 6
FIN33721 Tampere,
Finland
Phone:
Fax:
Email: Mika.saaranen@nokia.com
URI:
Barbara Stark
AT&T
725 W Peachtree St
Atlanta, GA 30076
US
Phone: +1 (404) 499-7026
Fax:
Email: barbara.stark@att.com
URI:
Baugher, et al. Expires September 9, 2009 [Page 21]