[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/