Internet Engineering Task Force S. Moyer Internet Draft D. Marples draft-moyer-sip-appliances-framework-02.txt S. Tsang J. Katz P. Gurung T. Cheng A. Dutta Telcordia Technologies H. Schulzrinne Columbia University Arjun Roychowdhury Hughes Software Systems Framework Draft for Networked Appliances using the Session Initiation Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document proposes the use of SIP for network-capable appliances. It leverages the standard SIP capabilities to directly communicate with appliances even when they are behind firewalls, NATs or other entities that prevent direct end-to-end communication. When combined with a new method type and the SIP event extensions these techniques become even more powerful. Contents Internet Draft SIP Appliances June 2001 1 Introduction...................................................2 1.1 Intra-Home Communication.......................................4 1.2 Extra-Home communication.......................................5 2 The Use of SIP for Extra-home communication....................6 2.1 Modifications and Extensions...................................7 2.1.1 Addressing..................................................7 2.1.2 New excitation Method.......................................7 2.1.3 New Payload Type(s).........................................8 2.1.4 Notification/Events.........................................8 3 Example Network Architectures..................................9 3.1 Example 1: Direct Communication with the Home Domain..........9 3.2 Example 2: Communication Via Gateway Proxy...................10 4 Example SIP Architecture......................................11 4.1 Functional/Logical Elements...................................12 4.2 Physical Realization..........................................14 5 Application Scenarios.........................................15 5.1 Simple Access to Home from Work...............................15 5.2 Access with Re-direction......................................18 5.3 Checking the Central Heating from the Office..................19 5.4 Answering the Front Doorbell from the Car.....................21 5.5 Establishing a Session with a Networked Appliance.............24 5.6 Querying the capabilities of a Networked Appliance............26 5.7 Forking for Services..........................................28 5.8 Device Grouping and personal Identification...................29 6 Security Considerations.......................................30 6.1 Security Threats..............................................30 6.1.1 Importance of Security.....................................30 6.1.2 Privacy....................................................31 6.1.3 Authentication.............................................31 6.2 Solutions.....................................................32 6.2.1 Security Using a Shared Secret.............................32 6.2.2 End-to-End Encryption......................................33 6.2.3 Encryption of the To: field................................34 7 Conclusion....................................................34 8 Acknowledgements..............................................35 A. Author's Addresses..........................................35 B. References..................................................35 C. Acronyms and Abbreviations..................................36 1 Introduction The next wave of the Internet is widely predicted to be the move towards the Networked Appliance (NA); The Fridge that can keep an inventory of your groceries and re-order when necessary or perhaps the alarm clock that can co-ordinate your agenda, the weather and the road conditions to determine the correct time to wake you up. It is clear that these appliances will need to communicate amongst themselves so that, for example, the alarm clock can turn on the S. Moyer et al. Expires December 2001 [Page 2] Internet Draft SIP Appliances June 2001 bedroom lamp, but the mechanism these appliances will use to communicate is far from obvious. This document provides the rationale behind the requirement for the standardization of these mechanisms and describes how to use the SIP architecture to meet these requirements. It further provides examples of how SIP can be used for this purpose. For the purpose of this document, Networked Appliances (NAs) are defined as dedicated (or limited) function consumer devices containing at least one networked processor. Examples include lamps, coffee makers and alarm clocks. Figure 1 provides an example of a home domain containing Networked Appliances. S. Moyer et al. Expires December 2001 [Page 3] Internet Draft SIP Appliances June 2001 +---------+ |Alarm | |Clock | +-------+ +----+----+ | | +-------+ | | | |Washing| | ---- | | |Machine| | //- -\\ |Firewall +---+---+ | / \ |or NAT | | | | | | | | | | | | | |Internal LAN | | Internet +--+-+ +--+------+------+------+--------- | | | | | | | | | | | | | | \ / | | | | | \\- -// | | | | | ---- | | | | | | | | | +----+---+ | +-------+ | | | | | +----+ LAC +----+ | +------+ | | +----+---+ | +-+SIP +---+ | | |Proxy | | | +------+ | | ******* /-------\ | ******* /Lamp \ | * * /----+--+---\ | ******* ******* | | | * * | | | *Coffee Maker * | | | *************** +-------+ | +-------+ <<---------------------+------------------------------------->> Outside World | In Home | Figure 1: Example Home Domain Containing Networked Appliances 1.1 Intra-Home Communication The primary advantage of using SIP for Network Appliances is that it provides connectivity across a wide area network. It is possible that within a home, devices are connected using existing technologies like X.10, Jini etc. It is also possible that SIP could be used within a home for device communication as a replacement technology for the existing intra-home protocols. Further, it can be envisioned that both SIP and other protocols co-exist within a S. Moyer et al. Expires December 2001 [Page 4] Internet Draft SIP Appliances June 2001 home (domain). Though this document stresses primarily inter-domain connectivity, it is equally possible to deploy SIP for intra-domain connectivity. For the purposes of this document, a home is considered to be a single (DNS) domain. Inter-device communication within a single domain can be subdivided into two essential issues; the location and identification of the device it is desired to talk to and then the communication with it. Some approaches separate these two issues explicitly although most tend to merge them into a single solution. There are numerous emerging standards for in-home inter-device communication (HAVi [4], VESA Home Networking [7], JINI [6] and UPnP [3] being four obvious examples) and there are other standards explicitly dedicated to location and identification of services (SLP [13] and Salutation [5] for example). Even allowing for the proliferation of intra-home communication standards, it is possible to identify a number of features that are common to each of them, as follows; - The rules that lead appliances to contact each other will either be coded in the appliance, or possibly downloaded from network servers. - These rules will be written in protocol specific terms such as Send a message to controller at IP address 10.23.45.67 port 2357, turn on item number 4555. - The way in which the mapping from protocol specific descriptions to human user-friendly descriptions is standard dependant, and is, in general, one of the less well developed aspects of the standards. 1.2 Extra-Home communication The development of techniques for access into the home from outside of it has not received anything like the attention that the in-home communication problem has. This is reasonable, given that one is predicated on the other. There are a number of additional factors that need to be accommodated when considering communication outside of the home, notably; - Security û In-home communication exploits a level of physical security that is lost when arbitrary access from outside of it is permitted. - Authentication û The entity trying to enter into the home needs to be unambiguously identified prior to permitting access. S. Moyer et al. Expires December 2001 [Page 5] Internet Draft SIP Appliances June 2001 - Reliability û Because of the wide-area nature of extra-home access, there are more points of failure. The home should continue to operate independently of external systems when communication with them is lost. - Scaling û there are very many homes. - Protocol Independence û Although within a single home it is acceptable that many different protocols are used for inter-device communication, a much more protocol-independent approach is required for the wide area, since the exact details of the devices comprising the in-home network may not be known from the outside world. - Naming and Location û Devices within the home need to be unambiguously named and their location identified from outside of it. Techniques are being developed to act as a beach-head into the home from the outside world, most notably by the Open Services Gateway Initiative (OSGi) [2] but this still does not address the general problem of wide area access, with the considerations above taken into account. Platforms such as the OSG may serve as the basis for such a set of techniques, however. 2 The Use of SIP for Extra-home communication This document outlines an architecture initially explicitly targeted to appliances but with more general applicability to any networked device, in which the location phase and communication (or action) phases are merged into a single activity. The requesting agent sends an instruction to perform an action on a named object in a message. The message contains the name of the object upon which the action should be performed as its address, and the action itself as the payload. This message is routed from agent to agent, resolving the name as it goes along. For example, the command Switch on the lamp in the master bedroom in DaveÆs house is first routed to the server that knows where DaveÆs house is. Then the message is onward routed to the DaveÆs house firewall, where access control and authorization is performed. If this is successful, the message payload is then delivered to the device to perform whatever action has been requested. We may easily observe that many of these concepts are already present in the Session Initiation Protocol (SIP). SIP performs exactly this routing by name function in the INVITE process. An INVITE is sent first to an agent, or proxy, for the name. The Proxy can rewrite the name and relay the INVITE, getting closer to the eventual destination for the message, delivering the payload (which is conventionally Session Description Protocol (SDP)) once it arrives. The Location and Action processes are intertwined in the S. Moyer et al. Expires December 2001 [Page 6] Internet Draft SIP Appliances June 2001 same procedure. In addition, the SIP security architecture enables verification based on these high level names. On initial consideration, it appears that SIP is capable of performing the functions identified above. There is, however, one essential difference between the capabilities of SIP and the identified requirements ù Addressing ù SIP URIs are, in practice, Internet DNS addresses. If this difference can be addressed, SIP becomes a very practical method of communicating with appliances. 2.1 Modifications and Extensions To address the issues identified above, the following modifications are proposed to SIP. These modifications and extensions are described in more detail in the Internet-Drafts [8] and [9]. 2.1.1 Addressing In SIP, the names that are found in the To: and From: fields are encoded as Universal Resource Locators (URL). Current implementations support SIP and PHONE URLs. One could define a new type of URL without changing the nature of the protocol. This allows for ôuser friendlyö discovery of the appliance address. An example, could use a format similar to the service URL syntax defined in RFC2609 but without the location information (which has already been determined via the SIP routing) and without the ôslp: prefix would be: d=lamp,r=bedroom By base64 encoding this URL (and potentially encrypting it to avoid revealing information about the types of devices contained in the domain) it is possible to structure this URL as part of a SIP URL; sip:a458fauzu3k3z@stan.home.net Thus, the existing structure of @ is maintained even when extended to accommodate appliances. However, it is not mandatory to use this proposed type of addressing scheme ù a standard SIP URL addressing scheme in either plaintext (e.g., toaster@stan.home.net) or with the portion to the left of the @ sign encrypted (e.g., a3245dsfs234@stan.home.net) are also valid addresses that will work. A structured addressing scheme could even be used in standard SIP addressing, e.g., lamp.bedroom@stan.home.net. 2.1.2 New excitation Method SIP was initially created with call set-up in mind. It is intended for establishing a relationship, or session, between two endpoints S. Moyer et al. Expires December 2001 [Page 7] Internet Draft SIP Appliances June 2001 such that ongoing bearer paths can be established between them. This structure could be generalized to cater for æshort-livedÆ connections if the connection establishment phase were removed and the payload generalized. The difference between the current way in which SIP is used and the proposed modifications is analogous in many ways to the difference between TCP and UDP or other Session/Datagram protocols. A new method is defined as part of the initiative to use SIP for Networked Appliances This method, called DO, meets the requirements identified above and can carry payloads other than SDP. Any MIME type could be used as the payload of a SIP command and new MIME types could easily be defined for Action Languages for particular classes of appliances. DO would carry the command that is appropriate for the target appliance, such as Turn The Light On. The command would trigger a single response, indicative of its result, which would be carried by the standard SIP response mechanisms. 2.1.3 New Payload Type(s) The typical MIME payload for SIP INVITE messages is SDP (Session Description Protocol). For networked appliances, a payload type that is specific for communicating with devices is required. We therefore propose a new MIME type called Device Messaging Protocol (DMP). The exact details of the DMP are still under investigation, but we believe it will be an XML-based specification that may be similar to Universal Plug 'n Play's Device Control Protocol [3]. In addition, when a device registers with a Proxy (via the REGISTER message) a description of that device needs to be conveyed. We propose to use a Device Description Protocol (DDP) to carry this information. Like the DMP, the exact details are still under development, but it also will likely be XML-based and will leverage existing work in this area. 2.1.4 Notification/Events In addition to synchronous communication with networked appliances, a need also exists for asynchronous communications. For example, to be notified when an alarm goes off in your home, a certain temperature is reached, or when someone rings your doorbell. The SIP Event Notification draft defines two new primitives, SUBSCRIBE and NOTIFY that can be used to achieve asynchronous communications. When these two methods are used in conjunction with the proposed addressing scheme (specified in section 2.1.1) and the Device Messaging Protocol MIME type, then event notification from and between networked appliances is enabled. S. Moyer et al. Expires December 2001 [Page 8] Internet Draft SIP Appliances June 2001 3 Example Network Architectures The architectures outlined in this section provide two different examples of how to support remote communication with networked devices. Note that actual implementations may use any combination of the two architectures described hereafter or something completely different. In the first, the client application is able to directly connect to and interact with the Home Domain. The second is when the client application must interact with a proxy located in the homeÆs gateway device in order to communicate with networked devices in the home. Both of these architectures are now described. 3.1 Example 1: Direct Communication with the Home Domain --- --- --- --- -- --- --- --- --- --- +---------+ -- -+ |Non-IP | -+ | |Appliance| | | +----+----+ | | | X | | appliance |/|\ message | -------- | specific | | in form of | //- -\\ | interface | | appliance spec. | // \\ | +-----+-----+ | / \ | |Appliance | | | | | |Controller | | | +--------+--+ +-----+-----+ | +--+--------+ ||Firewall | | X Home LAN | |originating| message || NAT +--------+/+\---+-+---------- | |application+----------->>| (RGW) | message| |\|/ message | +---+-------+ +--------+--+ +---------X------+ | | | | |Internet capable| | \ / | |Appliance | | \\ // | +----------------+ | \\- -// +--------------------------------+ -------- Wide Area Domain Home Domain Figure 2: Network Architecture: Direct Communication with the Home Domain The simplest architecture of the three examples allows a client application to directly connect to and interact with networked devices in the home domain. The wide area network is used to carry messages from a Client application to the Home Firewall/NAT. Once S. Moyer et al. Expires December 2001 [Page 9] Internet Draft SIP Appliances June 2001 authenticated, they are allowed through the firewall. Inside the home domain messages are transported over the Home LAN(s) to the appropriate Networked Device. Devices may either be æIP capableÆ (they can process the incoming messages themselves), or Non-IP- capable appliances. Non-IP-capable appliances require Appliance controllers to map IP control requests to the specific protocol and physical system that the Appliance can understand. This example is illustrated in Figure 2. 3.2 Example 2: Communication Via Gateway Proxy ---- ---- ---- ----- ---- ----- --- --- +-----------------+ --- ---| | Non-IP appliance| --| | +------X----------+ | | appliance| /|\message in the | | specific | | form of appliance | | area | | specific message | ------- | +---+-----+ | //- -\\ | |Appliance| | // \\ | |Controller | / \+-------++ +---+-----+ | | |Home | | \X/ | | message |Firewall| | /|\ | +--+--------+--------->>|NAT | | | Home LAN | |Client | |(RGW) +---------+---+------+---------- | |Application+-----------+| | message | | | +---+-------+ | /----\| | | | | +-/ * | | | \ / |Proxy | \|/ | | \\ // \ / X | | \\- -// \----| *\\-+----+ | ------- | |Internet| | | |Capable | | | |Appliance | | +--------+ | | | | | | | | | +----------------------------------+ Figure 3: Network Architecture: Communication via Gateway Proxy S. Moyer et al. Expires December 2001 [Page 10] Internet Draft SIP Appliances June 2001 In many cases, it will not be possible or desirable to allow client applications to directly access and control a userÆs Networked Appliances. This situation can occur for a number of reasons including: - The ApplianceÆs IP address cannot be determined because it is behind a NAT. - The Appliance does not have an IP address. - It is desired to keep visibility of in-home devices to a minimum. - The Home Firewall/NAT filters and rejects communications from unknown sources for security reasons. - Finer-grained security is desired (i.e. authentication and access control on a per device/message basis) In this case, control messages from Client Applications must first be sent to a ætrustedÆ Proxy, which has visibility into the home. This architecture is illustrated in Figure 3. All communications between the Proxy and the Home Firewall/NAT are assumed to be secure. In this case the Proxy is located in the home domainÆs gateway device. The proxy can provide a number of functions including: - Authenticate and authorize each message/request. - Address mapping/resolution for NAs within the home domain. - Act as secure proxy to Home Firewall/NAT (RGW) for communications to the outside world. - Provide NA mobility and tracking service. - Provide message protocol mapping service for client applications. By taking this approach, a variety of client applications can be supported for remote controlling NAs. - Act as charging point for services. 4 Example SIP Architecture This section describes an example of functional blocks that may be used in the SIP Architecture for supporting networked appliances. This is followed by typical ways in which these functional blocks can be realized in a practical system. S. Moyer et al. Expires December 2001 [Page 11] Internet Draft SIP Appliances June 2001 4.1 Functional/Logical Elements --- --- ---- --- --- --- +-----------+ ---- -- |Non-IP | --- --- |Appliance | ---- --- | | + --| | | | ----- | +-+---------+ | /// \\\ | | | / \ | +---Appliance specific | | Location | | Control interface-+ | | Database | | +--------------++ | | (Global) | | | Interworking | | \ / | | Unit (LAC) | | Appliance \\\ /// | +-----------------------+ registration --X-- | | SIP UA | & location /|\ | | (Appliance controller) | | | or RGW) | \|/ | +----------------+------+ +------/-----*----+ | | | | | | | | | SIP Proxy | | | | | (Service Provider) | +------SIP appliances | +---+--+----+----++ | | | | | | | | SIP | | + ---------+ | | Appliances| +----+SIP Proxy +---+----+ +----------+ | | |(RGW) | | |SIP UA | | +-+----+-+++ +--------+-+ | |(IP capable | | | | +----SIP appliances|Appliance)| | |SIP UA | | | +------+---+ | |originator+ | +----------+ | +--------+-+ +-------------------------------------+ Wide Area Network Home Domain Figure 4: Example Functional Architecture for Remote Communication with Networked Appliances This section outlines an example functional architecture for remote controlling Networked Appliances. The functional architecture (based on the Messaging via Proxy architecture of Figures 3 and 4) is illustrated in Figure 4. The functional entities can be distributed across different physical network elements (see Section 3) and this document only describes some of the possible distributions. The key functional entities are now described: - SIP UA (Originating domain): This SIP UA is used by the Originating application to generate and send Appliance messages (DO) to the SIP Proxy hosted by either the Service Provider or the Home RGW. S. Moyer et al. Expires December 2001 [Page 12] Internet Draft SIP Appliances June 2001 - SIP Proxy (Service Provider domain): The SIP proxy in the Service Provider domain resolves the address of the Appliance to be communicated with (including appropriate Home domain RGW) by lookup in a Location Database. The SIP proxy forwards Appliance messages from the Client SIP UA to the SIP Proxy in the Home Domain RGW or, via a secure connection, directly to the UA in the target device. - Location Database (Service Provider domain): The Service Provider Location Database contains location information for all registered appliances within the home domains. This database is populated with information gathered by the Service Provider SIP Proxy and/or other existing in-home service location protocols/mechanisms. - SIP Proxy (Home Domain RGW): The SIP Proxy in the Home Domain RGW provides the Gateway between Appliances in the Home Domain and entities in the wide area. Other RGW functions such as Firewall and NAT will likely be co-located with the RGW SIP Proxy. - SIP UA (Appliance Controller/RGW): This SIP UA terminates SIP Appliance messages from the Originating Application SIP UA. It retrieves messaging information from the SIP message and passes this information to the Interworking Unit. This SIP UA may reside in either the RGW or the Appliance Controller. The mapping from (logical) SIP UA to Appliance Controller is 1:N. - Interworking Unit (Appliance Controller): The Interworking Unit maps the Appliance message carried in the payload of the SIP message onto the Appliance-specific protocol. - SIP UA (IP capable appliance): This SIP UA resides in IP (SIP) capable NAs. It terminates SIP Appliance Control messages from the Originating Application SIP UA, and retrieves the Appliance Control information for the Appliance application, acting on it directly without any requirement for an intervening interworking unit. - Non-IP Capable Appliance: Non-IP Appliances are controlled by the Appliance Controller and require Interworking Units to communicate/interact with the Client Applications. The key interfaces in Figure 4 are: - SIP[Appliances]: This interface represents IETF SIP [11] with the DO method for communicating with Networked Appliances. - Appliance Registration and Location: Any appropriate database update and lookup protocol may be used to access the Location Databases. Examples of such a protocols are LDAP [12] and SLP [13]. - Appliance-Specific interfaces: There are numerous home-networking technologies currently available [1-6]. It is the function of the Interworking Unit to map from SIP to the protocols of the specific technology of the target device. S. Moyer et al. Expires December 2001 [Page 13] Internet Draft SIP Appliances June 2001 4.2 Physical Realization A possible physical realization of the theoretical system described above, following the same organization as in Figure 4, is shown in Figure 5 below. ----------- ----------- ------------ +----- -----+ | /--\ | | | | Non-IP Appliance | | \-+/ Light bulb | | | | | | | | +--Application specific control| | Interface | | | | | | | | +------+------+ | | |Interworking | | | |Unit | | | | | | +---------------+ | +---+---------+ | | | | | | |Service Provider | | | +-*---X---+-----+ | | | /|\ | | SIP[Appliances] | | | | | | | | \++-------+----+ | | | +---*Home Set-Top +---------------| | +--+ /|Box +-------------+ | +-+--+-+ *--------+----+ | | | | | | | +------+ | | | | +--SIP[Appliances]+ | PC in the | | | Office | | | Wide Area Network | | | +-------+-+| | +---+ Camcorder|| | +---+ || | +----------+| | SIP capable | | Appliance | -----------------------------------------+ Home Domain Figure 5. One Possible Physical Realization of Functional Architecture S. Moyer et al. Expires December 2001 [Page 14] Internet Draft SIP Appliances June 2001 In this diagram, the Originating SIP UA is on the PC in the user's office. They originate a message from this machine to manipulate an object within the home û perhaps a video camera or a light, for example. This message is forwarded, using standard SIP techniques, to the Service Provider who is responsible for the home, who sends it on to the Set Top Box (STB) (or RGW, or Cable Modem or ADSL Modem or whatever appropriate edge of home technology is deployed). The STB sends the message on either directly to the SIP-capable device (which will tend to be devices with higher capabilities such as video recorders and home audio-video equipment, HAVi notwithstanding), or indirectly via an Interworking Unit, which will be part of an appliance controller. The intention with the physical realization is to avoid the user needing to be aware of the level and sophistication of the communication that is being performed on their behalf. 5 Application Scenarios The following sub-sections provide examples of how SIP could be used for inter-domain networking of appliances. Note, not all SIP header fields (e.g. CSeq, Call-ID, and Content-length) are included in the following examples. For the sake of brevity, only the header fields of particular interest have been included. Also note that DMP has not yet been standardized and the DMP examples should be considered to be for illustration only. We do not comment on the practical validity of any given scenario. 5.1 Simple Access to Home from Work In this scenario, the user wishes to turn on a lamp within their home from their office PC. S. Moyer et al. Expires December 2001 [Page 15] Internet Draft SIP Appliances June 2001 ----- / \ | co.com | ---- \ / / \ \ / / \ +---+ / \ | X |services@home.| 2 | /|\ net <<------+ | +-----------------------+ | | | | +--------+ | | | | 1 | |SIP | | /\ +------+ / | | |UA | | X | stan | / | | +--|-+-*-+ |-----+ \+------+/ +--+--+ | | /|\ / \ +--- | | | 5 | |4 | | 3 | ++---++ | ---\<<--+ +----- services@ <<----------+ +--+---+-+ | /-++-\ | stan.home.net | | | || | | +--------+ | || \ / | ---- |---- anypc.co.com | stan.home.net | +-----------------------+ Figure 6. Simple Access to Home from Work The SIP messages for the remote control (e.g., from the office) of a NA within the home (e.g., a lamp) are shown below. Please note that the SLP URL information will be encoded and optionally encrypted for privacy, but is shown un-encrypted between [ and ] for clarity in the examples in this section. In the following example we assume that the UA in stan.home.net has registered with stan.home.net and that that information has also propagated to home.net. 1. DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On The co.com Proxy does an SRV look-up in DNS [15] for [d=lamp,r=bedroom,u=stanm]@home.net to find the name of the SIP server for the destination domain and gets a value of home.net. This implies that the user/service name must be unique within the service providerÆs domain when an SRV record points to a service providerÆs Proxy. 2. DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com S. Moyer et al. Expires December 2001 [Page 16] Internet Draft SIP Appliances June 2001 To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP co.com Via: anypc.co.com Content-function: render Content-type: application/dmp On 3. DO sip:[d=lamp,r=bedroom,u=stanm]@stan.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On 4. DO sip:[d=lamp,r=bedroom,u=stanm]@ua.stan.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On 5. The above scenario could also be used to depict a failure scenario. Once the lamp receives the message, it may realize that its bulb is "blown" (broken) and in response, send something like: 6. SIP /2.0 503 Service Unavailable From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/text Bulb has blown !! Replace with new! S. Moyer et al. Expires December 2001 [Page 17] Internet Draft SIP Appliances June 2001 5.2 Access with Re-direction In this case, the lamp from stan.home.net has temporarily been moved to simon.home.net. To accommodate the change, a re-direction is added into the home.net proxy. The SIP Messages for this scenario are shown below. In this example, we assume that the lamp from stan.home.net has been unregistered with both stan.home.net and home.net and that the UA in simon.home.net has performed the appropriate registrations. +---------------+ | +----+ | | |UA | +--+------------+ +------+ | | | | | | |stan | | +----+ | services@ | +--+------+--+ | | stan.home.net | | +------+ | +-------+ | | | | | | | | |stan.home.net--+------------+ | services@ | 2 | | +---------------+ | home.net |<<------+ co.com| | | | | | | +--/+\--+ +-----------------+ +---+--------+ | | +---+ | | |1 | |UA | | | | | | | 4 | 3 | +-+-+ | +-+-+<<------+-+--------------+ | | | | | | | <<-----+ +-+---+--+ | | | |services@simon| +--------+ | |5 | |.home.net | anypc.co.com | | | | + | |/\ | | | | | | +-+--------------+ + |-| | | | |Lamp | +----+-+----------+ simon.home.net Figure 7. Access with Re-direction 1. DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On 2. DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net S. Moyer et al. Expires December 2001 [Page 18] Internet Draft SIP Appliances June 2001 Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On The home.net proxy does a look-up and notices that Stan's bedroom lamp is now in Simon's spare room. Therefore, the Request-URI now points to the spare room in Simon's house. 3. DO sip:[d=lamp,r=spareroom,u=stanm]@simon.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On 4. DO sip:[d=lamp,r=bedroom,u=stanm]@ua.simon.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP simon.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp On 5. 5.3 Checking the Central Heating from the Office In this scenario, Stan is at work and wants to check the temperature of the downstairs zone of his two-zone heating and cooling system in his home. S. Moyer et al. Expires December 2001 [Page 19] Internet Draft SIP Appliances June 2001 +--------------------------+ | | | | |+--------+ | ||thermo- | ----- ||stat | /// \\\ ---- || | // | \\ ///- -\\\ || | | |services@ | / \ |+--+-*---+ | |stan.home.net 3 | services@home| | |/|\5 4 | | |<<----------+ .net | | | +-- +------<<-----+ | | | | | ----->> | \ | // \ / | 6 | UA +------>>\\ // \\\- -/// | | | 7 | ----- ----X | +------+ | /|\ | | | | stan.home.net | 2 | +--------------------------+ | -+-- +---+ // \\ | | 1 | | +-+---+-+------->>| co.com | | | | | +-------+ \\ // anypc.co.com -*-- Figure 8. Checking the House Temperature from Work 1. DO sip:[d=thermostat,r=downstairs,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=thermostat,r=downstairs,u=stanm]@home.net Via: SIP/2.0/UDP anypc.co.com Content-type: application/dmp Temperature 2. DO sip:[d=thermostat,r=downstairs,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=thermostat,r=downstairs,u=stanm]@home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-type: application/dmp Temperature 3. DO sip:[d=thermostat,r=downstairs,u=stanm]@stan.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=thermostat,r=downstairs,u=stanm]@home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com S. Moyer et al. Expires December 2001 [Page 20] Internet Draft SIP Appliances June 2001 Via: SIP/2.0/UDP anypc.co.com Content-type: application/dmp Temperature 4. DO sip:[d=thermostat,r=downstairs,u=stanm]@ua.stan.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=thermostat,r=downstairs,u=stanm]@home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-type: application/dmp Temperature 5. 6. Current temperature reading returned 7. 200 stan@co.com From: sip:[d=thermostat,r=downstairs,u=stanm]@home.net To: sip:stan@co.com Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-type: application/dmp 65F (this message is forwarded to request originator on anypc.co.com) The main differences between this example and the example in section 5.1 are: - a different body to issue a query for the temperature instead of a command to turn on the light - the removal of the Content-function header field since ôrenderö is the default value for this header field in a DO method (this is optional and it could have been left in). After Stan receives the temperature, he could issue another command to set the desired temperature. This would use a similar DO with a different body content. 5.4 Answering the Front Doorbell from the Car Stan is riding with Dave in DaveÆs car and remembers that he was expecting a service person to come and fix the dishwasher and he does not have his Web phone. He asks to borrow DaveÆs phone and sends a message to his service provider to notify him if someone S. Moyer et al. Expires December 2001 [Page 21] Internet Draft SIP Appliances June 2001 ôringsö the doorbell. When the service person ôringsö the doorbell (and authenticates themselves with their ID badge), a message is sent to DaveÆs Web phone for Stan indicating that the service person is at the front door. After verifying that it is indeed a person from the right company, Stan issues a command to unlock the front door and let the person in. For this scenario, the following assumptions are made: - Device Controller UA is configured to send outbound message to Proxy at stan.home.net - Dave's UA is configured to send outbound message to Proxy at mobile.net +-----------+ | | | | +------------------+ | home.net | 2,10 +--------+ |stan.home.net | | <<---------+ | | | +-+---------+ |mobile. | | +-----+ 4,12 +---+----+ | +------->>net | | | <<-----+stan.home 3,11 | | +-++-/|\-+ | | UA | 6 |.net <<---------+ | | | | | +----->> | | | | | | +++-+*+ | | +----------------------+ 8 | |1,9 | | /|\ +---+----+ 7 | | |13 | | | /-\|/-+--\ | | |5 | +--/ \ | +-V--++ + +---+-+---++---\ +-+-----+----------+ +-+ ++ | | dave.mobile.net | | | | | | +-----+ front door Figure 9. Answering the Front Door from a Car 1. 1. SUBSCRIBE sip:[d=door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp ring 2. SUBSCRIBE sip:[d=door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net S. Moyer et al. Expires December 2001 [Page 22] Internet Draft SIP Appliances June 2001 Contact: sip:stanm@dave.mobile.net Content-type: application/dmp ring 3. SUBSCRIBE sip:[d=door,r=front,u=stanm]@stan.home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp ring 4. SUBSCRIBE sip:[d=door,r=front,u=stanm]@ua.stan.home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp ring 5. (Doorbell Rings! Credentials established.) 6. NOTIFY stanm@dave.mobile.net SIP/2.0 From: sip:[d=door,r=front,u=stanm]@home.net To: stanm@dave.mobile.net Via: SIP/2.0/UDP ua.stan.home.net Content-type: application/dmp ring Maytag Repairman 7. NOTIFY stanm@mobile.net SIP/2.0 From: sip:[d=door,r=front,u=stanm]@home.net To: stanm@dave.mobile.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP ua.stan.home.net Content-type: application/dmp ring Maytag Repairman 8. NOTIFY stanm@dave.mobile.net SIP/2.0 From: sip:[d=door,r=front,u=stanm]@home.net To: stanm@dave.mobile.net Via: SIP/2.0/UDP mobile.net S. Moyer et al. Expires December 2001 [Page 23] Internet Draft SIP Appliances June 2001 Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP ua.stan.home.net Content-type: application/dmp ring Maytag Repairman 9. (User alerted and decides to unlock the door) DO sip:[d=door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stan@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP dave.mobile.net Content-type: application/dmp unlock 10. DO sip:[d=door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stan@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Content-type: application/dmp unlock 11. DO sip:[d=door,r=front,u=stanm]@stan.home.net SIP/2.0 From: sip:stan@dave.mobile.net To: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Content-type: application/dmp unlock 12. DO sip:[d=door,r=front,u=stanm]@ua.stan.home.net SIP/2.0 From: sip:stan@dave.mobile.net To: sip: sip:[d=door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Content-type: application/dmp unlock 13. 5.5 Establishing a Session with a Networked Appliance The previous application scenarios all involved session-less communications. It may be necessary to establish sessions with networked appliances. For example, consider an Internet Alarm Clock service where your wake-up time is adjusted based on current S. Moyer et al. Expires December 2001 [Page 24] Internet Draft SIP Appliances June 2001 weather, road, and traffic conditions. If the network-based alarm clock service provider adjusts your wake-up time, you would want to know why. So, then it would be convenient for the alarm clock service provider to establish an audio session with your alarm clock and "play" a message containing the reason(s) for the adjusted wake- up time (and maybe include the current weather, top news stories, etc.). The message flow for this scenario (depicted in Figure 10) would be as follows: ------ +-----------------+ / \ | | / \ | stan.home.net | / \ | | | | -- | |----- 2 | | //- -\\ | // \\<<------+ home.net | 1 / \ | | | | | <<--------+ | | +----+ 3 |stan.home| | | |alarmclock. | | UA |<<------+.net | | | | | |++-+-++ | | | \ / |com | ||6:18 | \\- -// \ / |+------+| |+-----+ | --- \ / \| |/ +-----------------+ ------ |\- -/| | -- | | UA | | | +------+ Figure 10. Network-based Alarm Clock Service SIP Message Flows 1. INVITE sip:[d=alarmclock,r=bedroom]@home.net SIP/2.0 From: sip:announcement@alarmclock.com To: sip:[d=lamp,r=bedroom]@stan.home.net Via: SIP/2.0/UDP alarmclock.com Content-type: application/sdp [SDP Parameters for uni-directional RTP stream] 2. INVITE sip:[d=alarmclock,r=bedroom]@stan.home.net SIP/2.0 From: sip:announcement@alarmclock.com To: sip:[d=lamp,r=bedroom]@stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP alarmclock.com Content-type: application/sdp [SDP Parameters for uni-directional RTP stream] 3. INVITE sip:[d=alarmclock,r=bedroom]@ua.stan.home.net SIP/2.0 From: sip: announcement@alarmclock.com To: sip: sip:[d=lamp,r=bedroom]@stan.home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net S. Moyer et al. Expires December 2001 [Page 25] Internet Draft SIP Appliances June 2001 Via: SIP/2.0/UDP alarmclock.com Content-type: application/sdp [SDP Parameters for uni-directional RTP stream] A response is then returned to the alarm clock service provider with the alarm clock's RTP parameters and an audio RTP stream is initiated (sent to the alarm clock). 5.6 Querying the capabilities of a Networked Appliance Wally's VCR broke down a few days ago. Today is Saturday and Wally wants to record the Simpson's cartoon show. He walks up to his office colleague, Dilbert who gives him permission to use his VCR to record the show. Wally knows Dilbert's VCR is a Sony Model, but does not know if it supports pre-programmed pause and resume for recording (to avoid commercial advertisements). Wally queries the VCR at Dilbert's Home to determine its capability set. Wally receives a response from the VCR telling him which video package this particular VCR supports as well as more detailed information in the body about the VCR. ------------- /// \\\ /// \\\ / ____ || ||""|| | | ||__|| | | [ -=.]`) | | ====== 0 | | | | | || 1| |6 || \ V | / \\\ -+--|// \\\ ///- ///-\\\ ----- -------/----- \ +-------------*//- -\\\ | | | 3 //| \\ 2 | office.com | | +-------| | dilbert. |<<-------| | | V | | home.net | | | |+---+--->>| | |-------->>\ / || UA| 4 \\| // 5 \\\- -/// |+---+-+ \\\- -/// ---- || VCR | | ----- |+-----+ | | | +-------------+ Figure 11. Querying device capabiltiites S. Moyer et al. Expires December 2001 [Page 26] Internet Draft SIP Appliances June 2001 1. OPTIONS sip:[d=vcr,r=den]@office.net SIP/2.0 From: sip:wally@office.com To: sip:[d=vcr,r=den@dilbert.home.net Via: SIP/2.0/UDP wallyville.office.com 2. OPTIONS sip:[d=vcr,r=den]@dilbert.home.net SIP/2.0 From: sip:wally@office.com To: sip:[d=vcr,r=den@dilbert.home.net Via: SIP/2.0/UDP office.com Via: SIP/2.0/UDP wallyville.office.com 3. OPTIONS sip:[d=vcr,r=den]@dilbert.home.net SIP/2.0 From: sip:wally@office.com To: sip:[d=vcr,r=den@dilbert.home.net Via: SIP/2.0/UDP dilbert.home.net Via: SIP/2.0/UDP office.com Via: SIP/2.0/UDP wallyville.office.com 4. SIP/2.0 200 OK From: sip:wally@office.com To: sip:[d=vcr,r=den@dilbert.home.net Via: SIP/2.0/UDP dilbert.home.net Via: SIP/2.0/UDP office.com Via: SIP/2.0/UDP wallyville.office.com Supported: com.sony.videopack.mm-extensions Content-Type:application/ddp 5. SIP/2.0 200 OK From: sip:wally@office.com To: sip:[d=vcr,r=den@dilbert.home.net Via: SIP/2.0/UDP office.com Via: SIP/2.0/UDP wallyville.office.com Supported: com.sony.videopack.mm-extensions Content-Type:application/ddp 6. SIP/2.0 200 OK From: sip:wally@office.com To: sip:[d=vcr,r=den@dilbert.home.net Via: SIP/2.0/UDP wallyville.office.com Supported: com.sony.videopack.mm-extensions S. Moyer et al. Expires December 2001 [Page 27] Internet Draft SIP Appliances June 2001 Content-Type:application/ddp 5.7 Forking for Services Calvin wants to print a document in his office. There are three printers in different floors that are capable of printing his document. Calvin contacts the default proxy server, which forks this request to the different printers. The available printer responds and Calvin CANCELS the other pending requests. For the sake of this example, let us suppose Calvin wants to establish a session with an available printer in which he will send the data once a confirmation is received. +---+----------+ 2 +--->>|UA | Printer A| ____ 1 +--+ +-------+ +---+----------+ ||""||--------->>|==+---+ 2 ||__||<<---------|==+--------------->>+---+----------+ [ -=.]`) 4 | |<<---------------|UA | Printer A| ====== 0 |--| 3 +---+----------+ +--+----+ 2 +-------+ +---+----------+ +-->>|UA | Printer A| +---+----------+ Figure 12.Forking service requests 1. INVITE sip:anyprinter@office.com SIP/2.0 From: sip:calvin@office.com To: sip:anyprinter@office.com Via: SIP/2.0/UDP calvin.office.com 2. Proxy forks the following messages: INVITE sip:printera@office.com SIP/2.0 From: sip:calvin@office.com To: sip:anyprinter@office.com Via: SIP/2.0/UDP hobbesproxy.office.com Via: SIP/2.0/UDP calvin.office.com INVITE sip:printerb@office.com SIP/2.0 From: sip:calvin@office.com To: sip:anyprinter@office.com Via: SIP/2.0/UDP hobbesproxy.office.com; branch=a1234 Via: SIP/2.0/UDP calvin.office.com S. Moyer et al. Expires December 2001 [Page 28] Internet Draft SIP Appliances June 2001 INVITE sip:printerc@office.com SIP/2.0 From: sip:calvin@office.com To: sip:anyprinter@office.com Via: SIP/2.0/UDP hobbesproxy.office.com; branch=a1234 Via: SIP/2.0/UDP calvin.office.com 3 Printer B responds with OK SIP/2.0 200 OK From: sip:calvin@office.com To: sip:anyprinter@office.com Via: SIP/2.0/UDP hobbesproxy.office.com; branch=a1234 Via: SIP/2.0/UDP calvin.office.com 4 SIP/2.0 200 OK From: sip:calvin@office.com To: sip:anyprinter@office.com Via: SIP/2.0/UDP calvin.office.com Proxy now proceeds to CANCEL all other pending requests. 5.8 Device Grouping and personal Identification SIP can also allow personal and group device identification. For example, using SIP, an air conditioner in Hagar's home domain could be addressed by the nickname of ôcoolboyö and at the same time also be known as a category of ôair conditionerö. This serves a two-fold purpose ù it allows owners to allocate personalities to their devices as well as, if needed, address a group irrespective of their nicknames. For example, to set the temperature of ôcoolboyö to 25 degrees C , Hagar can send 1. DO sip:[d=coolboy,r=room,u=hagar]@hagar.home.net SIP/2.0 From: sip:hagar@vacation.com To: sip:[d=coolboy,r=room,u=hagar]@hagar.home.net Via: SIP/2.0/UDP vacation.com Content-type: application/dmp Temperature 25C At the same time, if Hagar wanted to switch off all air conditioners in his house, he could multicast or broadcast the command. S. Moyer et al. Expires December 2001 [Page 29] Internet Draft SIP Appliances June 2001 2. DO sip:[group=airconditioner, u=hagar]@hagar.home.net SIP/2.0 From: sip:hagar@vacation.com To: sip:[group=airconditioner, u=hagar]@hagar.home.net Via: SIP/2.0/UDP vacation.com Content-type: application/dmp Off All network aware devices are configured to be a part of a group. For example, various air conditioner vendors may have their own schemes of private naming, but they all know they belong to the ôac- groupö of devices. So when such a message arrives, they know they are a part of it. Alternately, it is possible that a central Proxy or Appliance Controller is configured by the user or vendor of device groups in his house and once such a message arrives at the Proxy/Controller, it sends an appropriate DO command to each device in this group. 6 Security Considerations Security is a primary concern, especially since this system is intended for deployment in individual userÆs homes. We briefly outline here the security threats that are applicable to the protocol described herein, and which must be considered in any implementation of this protocol. We also discuss some possible approaches to deal with the security issues raised. We point out that there are security concerns raised by this document, which are, however, outside the scope of the present discussion. In this discussion, we only consider security of the underlying SIP protocol (as it relates to networked appliances). We also assume (physical) security of the userÆs home; in other words, our analysis assumes that only on the Internet can an adversary eavesdrop on SIP messages, forge SIP messages, and modify SIP messages. 6.1 Security Threats 6.1.1 Importance of Security Security concerns must be paramount when designing a system, which allows remote access to a home. A forged (generic) SIP message will usually be no more than an annoyance, but a forged command to turn on an appliance within someone else's home is a potential disaster. Therefore, methods for verifying authenticity MUST be provided in any system that allows remote home access. In particular, all (SIP) communication to the home MUST be authenticated by the home RGW/firewall, and verified to have originated from either an authorized individual (in the case of direct communication from user S. Moyer et al. Expires December 2001 [Page 30] Internet Draft SIP Appliances June 2001 to the home, as in Figure 3) or an authorized Service Provider Proxy (in the case of communication via proxy, as in Figure 4). In the second case, the Service Provider Proxy also MUST have verified that communication originated from an individual authorized to communicate with the home. Privacy will be a concern for many users, particularly since messages contain information about the existence and use of appliances within their home. Thus, implementations MUST provide methods for private (i.e., encrypted) communication. However, users may choose to opt out (but they MUST NOT be allowed to opt out of checking proper authentication, as detailed above). Security of message responses is important as well. These responses may eventually contain status information (i.e., the current temperature of the house, and faked 100 and 200 response messages can also cause problems. 6.1.2 Privacy In general, a user will not want a passive eavesdropper to be able to determine the content of a message. This applies not only to the body of the message (which will contain the command to be executed), but also to header fields that may leak information about the devices one owns. For example, the To: header field will contain a URL of the addressed entity which, as proposed in Section 2.1.1, will indicate the device type and location. A user may not want anyone to know whether he owns a television, and he certainly will not want anyone to know the room in which the television is located. If the underlying architecture being implemented provides direct control of the home domain, no intermediate proxies need be trusted (with respect to privacy) because appropriate fields can be suitably encrypted. However, if the underlying architecture is communication via Proxy (e.g., deployed in the service provider's network), an assumption of trust of the intervening Proxy is inevitable. REGISTER messages may also require encryption, if registration takes place in a network outside the home (as it would in the case of communication via Proxy). 6.1.3 Authentication From the userÆs point of view, an even more important concern is proper authentication of SIP messages. Note that messages in either direction (from user to home or from home to user) require authentication. The authentication requirement on messages from user to home is obvious, since these are messages, which will effect certain actions inside the home. However, 100 and 200 response messages from the home to the user must also be authenticated, lest S. Moyer et al. Expires December 2001 [Page 31] Internet Draft SIP Appliances June 2001 an adversary insert a fake Acknowledge or Confirmed message when in fact the original message was never received. Also, responses may eventually include status information, such as the temperature of the house or whether the alarm system is turned on. In addition to authentication of DO messages, REGISTER messages may also potentially require authentication. However, if registration is done with the home RGW (as would be the case when direct communication (Figure 3) is assumed), cryptographic solutions are not necessary (due to the physical security of the home network). When registration takes place in an outside network (as when Communication via Proxy is used), these messages must be authenticated. Authentication of messages will prevent fabrication, modification, and masquerading. An issue not directly resolved by authentication is replay attacks. Replay attacks can be defended against in two ways. One simple way to do this is to check for repeated messages; this can be done, for example, by checking the Timestamp: or CSeq: fields against previously stored messages. However, there is a limit to the number of previously used Timestamps can be stored, and this leaves open the possibility of replaying a (very) old message. A more robust solution is to check for old messages by comparing the Timestamp: field to the current system time. Note that the Timestamp: field cannot be maliciously modified because of the assumed message authentication being used. In this case, however, some synchronization of clocks is assumed 6.2 Solutions Methods for achieving privacy and authentication for (generic) SIP messages appear in [11] and, in general, these methods apply to the case of addressing NAs as well. However, we highlight a few important differences between general SIP security and the specific case of remote home access. 6.2.1 Security Using a Shared Secret For general SIP security, some form of public-key technology must be employed to provide security [11]. In the case of remote access to NAs within the home, however, shared secrets can be used to provide privacy and authentication. The are two primary reasons for this difference: first, general SIP communication can potentially occur between any two parties, while in the case of remote access to the home a one-to-one (or few-to-one) correspondence exists between authorized users and the homes to which they will be communicating. Second, general SIP communication frequently occurs between parties who have had no prior contact, and therefore no opportunity to generate a shared secret. In the case of home access, however, users will have the opportunity to designate a shared secret for use in S. Moyer et al. Expires December 2001 [Page 32] Internet Draft SIP Appliances June 2001 their communication with the home. The secret may be shared either with the home RGW/firewall (in the case of direct communication from user to the home, as in Figure 1) or with the Service Provider Proxy (in the case of Communication via Proxy, as in Figure 4). In general, secret-key methods are preferable to public-key methods due to both their higher level of security and increased efficiency. Note that in some cases, public-key methods may be preferable. It may be advantageous to provide implementations for both. Implementation details will depend on outside factors including the requirements of the service provider, initial installation, billing, record keeping, supported remote access methods, and future upgradability. 6.2.2 End-to-End Encryption The SIP RFC [11] describes two methods of achieving privacy: encrypt end-to-end or hop-by-hop. In the particular setting of remote access to the home, we recommend that only end-to-end encryption be used. End-to-end encryption is certainly more efficient, and if the user and the home RGW/firewall (or Service Provider Proxy) share a secret key, there is no need to rely on hop-by-hop encryption. Furthermore, hop-by-hop encryption requires trust in every proxy along the message path, while end-to-end encryption only requires trust in the final UA that performs the decryption (either the home RGW/firewall or the Service Provider Proxy). We distinguish two cases. First, as in Figure 3, we may have direct communication from the user to the home where decryption and verification of authenticity are done by the home RGW/firewall. In this case, the original message from the user can be encrypted and authenticated using the secret key shared by the user and the home. In the second case, communication is via Proxy outside of the home domain (e.g., a service provider deployed Proxy). In this scenario, the message from the user is first encrypted and authenticated using a key shared between the user and the service provider's Proxy. Upon receipt of the message, the service provider's Proxy verifies the authenticity of the message and decrypts. Then, the message is authenticated and encrypted using a key shared between the service provider's Proxy and the home and forwarded to the home (note that this step may also be handled by the establishment of a secure IPSec tunnel between the service provider's Proxy and the home). The forwarded message is authenticated (as having come from the service provider's Proxy) and decrypted by the home RGW/firewall before being allowed inside the home. (Although technically this is no longer end-to-end encryption, we prefer to think of it that way since there will be many intermediate proxies along the path from S. Moyer et al. Expires December 2001 [Page 33] Internet Draft SIP Appliances June 2001 user to the service provider's Proxy, and the message is not re- encrypted for each hop.) 6.2.3 Encryption of the To: field One major difference between this document and [11] is that the To: header field now contains potentially sensitive information (such as device names and locations) which should be encrypted. The body of the message (and appropriate header fields) should be encrypted as detailed in [11] (although possibly using private-key technology). Encryption of the To: field should take place separately from encryption of the body of the message. Since the entire contents of the To: field cannot be encrypted (this information is used for routing), only the portion to the left of the ô@ö (the entity information) should be encrypted. At first glance, this might appear problematic since routing is done based on entity information contained in the To: field. We show that this problem is easily avoided. Indeed, routing is done based on two components of the To: field: the entity name (appearing to the left of the ô@ö) and the location (appearing to the right of the ô@ö). Information about the location component (typically domain-names) is available to every proxy in the network. On the other hand, information about specific entities is (typically) only available to a select few proxies (in particular, the home RGW/firewall when assuming direct communication from user to the home, or the Service Provider Proxy when assuming communication via proxy). Thus, for most proxies, routing will be based solely on the location component of the To: field, and they therefore have no need to examine the entity component. On the other hand, proxies that do need to see the contents of the entity component will have the decryption key available to them (since the encryption was done with the appropriate shared key). Thus, routing will proceed via the location component until the message reaches a proxy that has access to information concerning specific devices within that domain. This proxy, by construction, will also have access to the correct key for decrypting (and authenticating) the message. Upon decrypting the message, and in particular the entity component of the To: field, the proxy can correctly route the message using this additional information. 7 Conclusion We have shown how SIP, with the newly proposed DO, SUBSCRIBE, and NOTIFY messages, plus the new MIME types, and new mechanism for encoding service information in the To: field can provide the support necessary for communication with networked appliances from the wide area. This proposal enables leveraging the existing SIP infrastructure and capabilities (e.g., hop-by-hop routing and security) for a new problem domain ù networked appliances. S. Moyer et al. Expires December 2001 [Page 34] Internet Draft SIP Appliances June 2001 8 Acknowledgements The author's would also like to thank and acknowledge the contributions of Steven Ungar, Mike Little and Christian Huitema, without whose input this work would not have been possible. A. Author's Addresses Stanley Moyer e-mail: stanm@research.telcordia.com Dave Marples e-mail: dmarples@research.telcordia.com Simon Tsang e-mail: stsang@research.telcordia.com Jonathan Katz e-mail: jkatz@research.telcordia.com Provin Gurung e-mail: pgurung@research.telcordia.com Thanh Cheng e-mail: thanh@research.telcordia.com Ashutosh Dutta e-mail: adutta@research.telcordia.com All of the above are at; Telcordia Technologies Inc. 445 South Street Moristown, NJ 07960, USA. Henning Schulzrinne Department of Computer Science Columbia University M/S 0401 1214 Amsterdam Avenue New York, NY 10027-7003 e-mail:hgs@cs.columbia.edu Arjun Roychowdhury Hughes Software Systems Prestige Opal 146 Infantry Road Bangalore 560001, India. e-mail: archow@hss.hns.com B. References [1] Tsang, et al, "Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking ", Internet Draft draft-tsang- appliances-reqs-01.txt, September 2000 [2] OSGi, www.osgi.org. [3] UPnP, www.upnp.org. [4] HAVi, www.havi.org. [5] Salutation, www.salutation.org. [6] JINI, www.jini.org. [7] VESA Home Networking, www.vesa.org. S. Moyer et al. Expires December 2001 [Page 35] Internet Draft SIP Appliances June 2001 [8] S. Tsang, et al., ôSIP Extensions for Communicating with Networked Appliances,ö Internet Draft draft-tsang-sip-appliances- do-00.txt, November, 2000. [9] J. Rosenberg, et al., ôA Protocol for Presence based on SIP,ö Internet Draft draft-rosenberg-impp-presence-00.txt, June 6, 2000. [10] UPnP Device Control Protocol, www.upnp.org. [11] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, March 1999. [12] T. Howes, and M. Smith, "The LDAP URL Format", Request For Comments (Proposed Standard) 2255, December 1997. [13] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol, Version 2", Request For Comments 2608, June 1999. [14] E. Guttman, C. Perkins, and J. Kemp, "Service Templates and Service:Schemes", Request for Comments 2609, June 1999. [15] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)," Request for Comments 2782, February 2000. C. Acronyms and Abbreviations ADSL Asynchronous Digital Subscriber Line CHAP Challenge-Handshake Authentication Protocol DDP Device Description Protocol DMP Device Messaging Protocol DNS Domain Name Service HAVi Home Audio/Video Interoperability IETF Internet Engineering Task Force IP Internet Protocol IPSec IP Security JINI JINI Is Not Initials LAN Local Area Network Multi-purpose Internet Mail Extension [or Multimedia MIME ....] NA Networked Appliance NAT Network Address Translator OSGi Open Services Gateway Initiative PGP Pretty Good Privacy RGW Residential Gateway SDP Session Description Protocol SIP Session Initiation Protocol S. Moyer et al. Expires December 2001 [Page 36] Internet Draft SIP Appliances June 2001 SLP Service Location Protocol TCP Transmission Control Protocol UA (SIP) User Agent UDP User Datagram Protocol UPnP Universal Plug and Play URL Universal Resource Locator VESA Video Electronics Standards Association XML Extensible Markup Language S. Moyer et al. Expires December 2001 [Page 37]