Universal Plug and Play (UPnP)
Wednesday, June 24, 2009 Publications by Jem's
UPnP
Universal Plug and Play (UPnP) is a set of networking protocols promulgated by the UPnP Forum. The goals of UPnP are to allow devices to connect seamlessly and to simplify the implementation of networks in the home (data sharing, communications, and entertainment) and in corporate environments for simplified installation of computer components. UPnP achieves this by defining and publishing UPnP device control protocols built upon open, Internet-based communication standards.
The term UPnP is derived from plug-and-play, a technology for dynamically attaching devices directly to a computer, although UPnP is not directly related to the earlier plug-and-play technology. UPnP devices are "plug-and-play" in that when connected to a network they automatically announce their network address and supported device and services types, enabling clients that recognize those types to immediately begin using the device.
Overview
The UPnP architecture allows peer-to-peer networking of PCs, networked home appliances, CE devices and wireless devices. It is a distributed, open architecture protocol based on established standards such as TCP/IP, UDP, HTTP, XML, and SOAP.
The UPnP architecture supports zero-configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices. DHCP and DNS servers are optional and are only used if they are available on the network. Devices can leave the network automatically without leaving any unwanted state information behind.
UPnP was published as a 73-part International Standard, ISO/IEC 29341, in December, 2008.
Other UPnP features include:
Media and device independence
UPnP technology can run on many media that support IP including Ethernet, FireWire, IR (IrDA), home wiring (G.hn) and RF (Bluetooth, Wi-Fi). No special device driver support is necessary; common protocols are used instead.
User interface (UI) Control
UPnP architecture enables devices to present a user interface through a web browser (see Presentation below).
Operating system and programming language independence
Any operating system and any programming language can be used to build UPnP products. UPnP does not specify or constrain the design of an API for applications running on control points; OS vendors may create APIs that suit their customer's needs.
Programmatic control
UPnP architecture also enables conventional application programmatic control.
Extensibility
Each UPnP product can have device-specific services layered on top of the basic architecture. In addition to combining services defined by UPnP Forum in various ways, vendors can define their own device and service types, and can extend standard devices and services with vendor-defined actions, state variables, data structure elements, and variable values.
Protocol
Addressing
The foundation for UPnP networking is IP addressing. Each device must have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device is first connected to the network. If no DHCP server is available, that is, the network is unmanaged, the device must assign itself an address. The process by which a UPnP device assigns itself an address is known within the UPnP Device Architecture as "AutoIP". In UPnP Device Architecture Version 1.0, AutoIP is defined within the specification itself; in UPnP Device Architecture Version 1.1, AutoIP references IETF RFC 3927. If during the DHCP transaction, the device obtains a domain name, for example, through a DNS server or via DNS forwarding, the device should use that name in subsequent network operations; otherwise, the device should use its IP address.
Discovery
Given an IP address, the first step in UPnP networking is Discovery. The UPnP discovery protocol, defined in Section 1 of the UPnP Device Architecture, is known as the Simple Service Discovery Protocol (SSDP). When a device is added to the network, SSDP allows that device to advertise its services to control points on the network. Similarly, when a control point is added to the network, SSDP allows that control point to search for devices of interest on the network. The fundamental exchange in both cases is a discovery message containing a few, essential specifics about the device or one of its services, for example, its type, identifier, and a pointer to more detailed information.
Description
After a control point has discovered a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device's description from the URL provided by the device in the discovery message. The UPnP description for a device is expressed in XML and includes vendor-specific, manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. For each service, the description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action; the description for a service also includes a list of variables; these variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics.
Control
Having retrieved a description of the device, the control point can send actions to a device's service. To do this, a control point sends a suitable control message to the control URL for the service (provided in the device description). Control messages are also expressed in XML using the Simple Object Access Protocol (SOAP). Much like function calls, the service returns any action-specific values in response to the control message. The effects of the action, if any, are modeled by changes in the variables that describe the run-time state of the service.
Event notification
The next step in UPnP networking is event notification, or "eventing". The event notification protocol defined in the UPnP Device Architecture is known as GENA, an acronym for "General Event Notification Architecture". A UPnP description for a service includes a list of actions the service responds to and a list of variables that model the state of the service at run time. The service publishes updates when these variables change, and a control point may subscribe to receive this information. The service publishes updates by sending event messages. Event messages contain the names of one or more state variables and the current value of those variables. These messages are also expressed in XML. A special initial event message is sent when a control point first subscribes; this event message contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the service. To support scenarios with multiple control points, eventing is designed to keep all control points equally informed about the effects of any action. Therefore, all subscribers are sent all event messages, subscribers receive event messages for all "evented" variables that have changed, and event messages are sent no matter why the state variable changed (either in response to a requested action or because the state the service is modeling changed).
UPnP AV standards
UPnP AV stands for UPnP Audio and Video. On 12 July 2006 the UPnP Forum announced the release of version 2 of the UPnP Audio and Video specifications (UPnP AV v2), with new MediaServer version 2.0 and MediaRenderer version 2.0 classes. These enhancements are created by adding capabilities to the UPnP AV MediaServer and MediaRenderer device classes that allow a higher level of interoperability between MediaServers and MediaRenderers from different manufacturers. Some of the early devices complying with these standards were marketed by Philips under the Streamium brand name.
The UPnP AV standards have been referenced in specifications published by other organizations including Digital Living Network Alliance Networked Device Interoperability Guidelines, International Electrotechnical Commission IEC 62481-1, and Cable Television Laboratories OpenCable Home Networking Protocol.
UPnP AV components
* UPnP MediaServer DCP - which is the UPnP-server (a 'master' device) that shares/streams media-data (like audio/video/picture/files) to UPnP-clients on the network.
* UPnP MediaServer ControlPoint - which is the UPnP-client (a 'slave' device) that can auto-detect UPnP-servers on the network to browse and stream media/data-files from them.
* UPnP MediaRenderer DCP - which is a 'slave' device that can render content.
* UPnP RenderingControl DCP - control MediaRenderer settings; volume, brightness, RGB, sharpness, and more).
* UPnP Remote User Interface (RUI) client/server - which sends/receives control-commands between the UPnP-client and UPnP-server over network, (like record, schedule, play, pause, stop, etc.).
Web4CE (CEA 2014) for UPnP Remote UI - CEA-2014 standard designed by Consumer Electronics Association's R7 Home Network Committee. Web-based Protocol and Framework for Remote User Interface on UPnP Networks and the Internet (Web4CE). This standard allows a UPnP-capable home network device to provide its interface (display and control options) as a web page to display on any other device connected to the home network. That means that you can control a home networking device through any web-browser-based communications method for CE devices on a UPnP home network using ethernet and a special version of HTML called CE-HTML.
QoS (Quality of Service) - is an important (but not mandatory) service function for use with UPnP AV (Audio and Video). QoS (Quality of Service) refers to control mechanisms that can provide different priority to different users or data flows, or guarantee a certain level of performance to a data flow in accordance with requests from the application program. Since UPnP AV is mostly to deliver streaming media that is often near real-time or real-time audio/video data which it is critical to be delivered within a specific time or the stream is interrupted. QoS (Quality of Service) guarantees are especially important if the network capacity is limited, for example public networks, like the internet.
QoS (Quality of Service) for UPnP consist of Sink Device (client-side/front-end) and Source Device (server-side/back-end) service functions. With classes such as; Traffic Class that indicates the kind of traffic in the traffic stream, (for example, audio or video). Traffic Identifier (TID) which identifies data packets as belonging to a unique traffic stream. Traffic Specification (TSPEC) which contains a set of parameters that define the characteristics of the traffic stream, (for example operating requirement and scheduling). Traffic Stream (TS) which is a unidirectional flow of data that originates at a source device and terminates at one or more sink device(s).
NAT traversal
One solution for NAT (Network Address Translation) traversal, called the Internet Gateway Device (IGD) Protocol, is implemented via UPnP. Many routers and firewalls expose themselves as Internet Gateway Devices, allowing any local UPnP controller to perform a variety of actions, including retrieving the external IP address of the device, enumerate existing port mappings, and adding and removing port mappings. By adding a port mapping, a UPnP controller behind the IGD can enable traversal of the IGD from an external address to an internal client.
Problems with UPnP
Lack of Default Authentication
The UPnP protocol, as default, does not implement any authentication, so UPnP device implementations must implement their own authentication mechanisms, or implement the Device Security Service. There also exists a non-standard solution called UPnP-UP (Universal Plug and Play - User Profile) which proposes an extension to allow user authentication and authorization mechanisms for UPnP devices and applications.
Unfortunately, many UPnP device implementations lack authentication mechanisms, and by default assume local systems and their users are completely trustworthy.
Most notably, routers and firewalls running the UPnP IGD protocol are vulnerable to attack since the framers of the IGD implementation omitted a standard authentication method. For example, Adobe Flash programs are capable of generating a specific type of HTTP request. This allows a router implementing the UPnP IGD protocol to be controlled by a malicious web site when someone with a UPnP-enabled router simply visits that web site. The following changes can be made silently by code embedded in an Adobe Flash object hosted on a malicious website:
* Port forward internal services (ports) to the router external facing side (i.e. expose computers behind a firewall to the Internet).
* Port forward the router's web administration interface to the external facing side.
* Port forwarding to any external server located on the Internet, effectively allowing an attacker to attack an Internet host via the router, while hiding their IP address.
* Change DNS server settings so that when victims believe they are visiting a particular site (such as an on-line bank), they are redirected to a malicious website instead.
* Change the DNS server settings so that when a victim receives any software updates (from a source that isn't properly verified via some other mechanism, such as a checking a digital certificate has been signed by a trusted source), they download malicious code instead.
* Change administrative credentials to the router/firewall.
* Change PPP settings.
* Change IP settings for all interfaces.
* Change WiFi settings.
* Terminate connections.
This only applies to the "firewall-hole-punching"-feature of UPnP; it does not apply when the IGD does not support UPnP or UPnP has been disabled on the IGD. Also, not all routers can have such things as DNS server settings altered by UPnP because much of the specification (including LAN Host Configuration) is optional for UPnP enabled routers
Other Issues
UPnP uses HTTP over UDP (known as HTTPU and HTTPMU for unicast and multicast), even though this is not standardized and is specified only in an Internet-Draft that expired in 2001.
UPnP does not have a lightweight authentication protocol, while the available security protocols are complex. As a result, some UPnP devices ship with UPnP turned off by default as a security measure.
Future developments
The standard DPWS is a candidate successor for UPnP. It solves many of the problems of UPnP. A DPWS client is included in Microsoft Windows Vista as part of the Windows Rally technologies.
Another alternative, NAT-PMP, is an IETF draft introduced by Apple Inc. in 2005.
UPnP 1.1 has in fall 2008 been ratified by the UPnP forum as successor for UPnP 1.0.
References
- http://www.iec.ch/news_centre/release/nr2008/nr4008.html
- http://www.iso.org/iso/pressrelease.htm?refid=Ref1185
- http://www.upnp.org/news/documents/UPnPForum_02052009.pdf
- http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf
- http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
- http://www.ietf.org/rfc/rfc3927.txt
- http://www.dlna.org/industry/certification/guidelines
- http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=cat-det.p&progdb=db1&wartnum=038283
- http://www.cablelabs.com/specifications/OC-SP-HNP-I01-060630.pdf
- http://www.ce.org/Standards/browseByCommittee_2757.asp
- http://www.upnp.org/standardizeddcps/security.asp
- http://www.upnp-up.org/
- http://www.shorewall.net/UPnP.html
- http://linux-igd.sourceforge.net/documentation.php#SECURITY
- http://www.gnucitizen.org/blog/hacking-the-interwebs
- http://www.gnucitizen.org/blog/flash-upnp-attack-faq
- http://www.upnp.org/standardizeddcps/igd.asp
- http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/30/30482/01405701.pdf?temp=x
Books
* Golden G. Richard: Service and Device Discovery : Protocols and Programming, McGraw-Hill Professional, ISBN 0-07-137959-2
* Michael Jeronimo, Jack Weast: UPnP Design by Example: A Software Developer's Guide to Universal Plug and Play, Intel Press, ISBN 0-9717861-1-9
External links
- http://upnp.org/standardizeddcps/default.asp
- http://www.upnp-database.info/ Community-based database of UPnP/AV Devices.
Source: www.wikipedia.org
Posts
0 comments:
Post a Comment