SIPPING Working Group J. Littlefield Internet-Draft Cisco Systems, Inc. Expires: December 17, 2006 June 15, 2006 A Management Request Event Package for the Session Initiation Protocol (SIP) draft-littlefield-sipping-mgmt-event-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 December 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In many environments, firewall, NAT and IP addressing issues make remote management of devices containing SIP user agents difficult. This document defines a SIP event package for notifying a device that it should connect to a management entity for management operations. This type of "call-home" management avoids the need to maintain persistent TCP connections to, or generate additional STUN traffic with, the management entity. Littlefield Expires December 17, 2006 [Page 1] Internet-Draft SIP Management Request Event Package June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overiew of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. Management Request Event Package . . . . . . . . . . . . . . . 5 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 5 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5 4.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 6 4.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 6 4.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 6 4.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 4.10. Handling of Forked Requests . . . . . . . . . . . . . . . 7 4.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 7 4.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 4.13. Examples of Usage . . . . . . . . . . . . . . . . . . . . 8 5. Management Protocol List Documents . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.1. SIP Event Package Registration for "management-request" . 9 7.2. MIME Registration for "application/mgmt-protos-list" . . . 10 8. Normative Referneces . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Littlefield Expires December 17, 2006 [Page 2] Internet-Draft SIP Management Request Event Package June 2006 1. Introduction Device management is an important tool for troubleshooting and monitoring network entities. When devices are directly addressable, and their addresses are known or easily resolved using DNS (Domain Name System), device management protocols such as SNMP (Simple Network Management Protocol) work well for retrieving device statistics and for examining and changing device settings and state. However, when NAT (Network Address Translator), NATP (NAT Protocol Translation) and firewall devices are between the managed device and the management station, it may be difficult or impossible to initiate communication with the device in the normal way. Examples of such deployments include service providers attempting to manage devices deployed in a subscribers home, behind a typical home gateway device, as well as some multi-site enterprises. Aside from remote manipulation of the firewall and NAT devices, these deployments typically require some form of "call-home" management, where the managed entity takes the initiative in establishing the management session or allowing for management transactions. Among the less attractive solutions to this problem are to have the managed device maintain a persistent TCP connection to the management station, or to use STUN or similar frequent UDP exchanges to maintain a firewall pinhole or NATP port-mapping through which it may be reached. An alternative is to use some out-of-band mechanism by which the device can be contacted to notify the device of the need for it to contact the management station for management using a standard management protocol. When the device contains a Session Initiation Protocol (SIP) [2] user agent (and specifically when the device's primary role is that of a SIP user agent), its attractive to use SIP messaging to request that the device initiate a management session. The NAT and firewall traversal issues will have already been solved for SIP messaging, and the ability to address the device using a SIP URI rather than a hostname or IP address may be attractive as well, especially for an overlay voice service provider. The use of SIP to establish management sessions has limitations in that it depends on the device's ability to successfully use SIP, so this approach may not allow diagnosis and correction of a severely incapacitated device. However, there are still significant benefits over the complete lack of manageability. This document defines a SIP event package which allows the SIP user agent to subscribe to and receive notification of requests for management connections from a particular management domain. It does not specify the management protocol to use, but allows for a variety of management protocols. It does not restrict notification content, Littlefield Expires December 17, 2006 [Page 3] Internet-Draft SIP Management Request Event Package June 2006 in anticipation of supporting a variety of notification content appropriate to different protocols. This event package considered complementary to the event package specified by the SIP user agent (UA) profile delivery framework [4], which defines mechanisms for configuration, but not management, of SIP user agents. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. 3. Overiew of Operation When using this event package, the device begins with the name of the domain to which it belongs for management purposes. This domain name may be discovered via DHCP, manually configured, or obtained as part of a separate device configuration download (using the Sip UA profile delivery framework, for example). This domain name enables the device to form a unique request URI to which it will subscribe using this event package. The subscription request from the device contains information about the management protocol or protocols that the device supports and expects to use. In many situations, there is standard and well-known management protocol to use, such as in the case of home telephony adapter devices managed by a service provider and conforming to a particular access network technology service standard. In other situations, the device's configuration will dictate which of a set of possible management protocols are to be used. In some situations, multiple transports of the same management protocol may be acceptable, and the device would indicate which of those protocols it supports. When the management station needs to contact the device to perform management operations, it sends a NOTIFY message to the device including information about the management protocol to use. In some cases, this may include information about which management station to contact, but in many cases the management protocol contact information for the management station will be part of the device's configuration, and the NOTIFY will simply indicate the need to establish a session with this pre-configured station (or one of several). Littlefield Expires December 17, 2006 [Page 4] Internet-Draft SIP Management Request Event Package June 2006 On receipt of the notification, the managed device immediately connects to the management station using the negotiated management protocol. Authentication of this management session is dependent on the management protocol, device configuration, and authorization requirements of the device and the management station. 4. Management Request Event Package 4.1. Event Package Name This document defines a SIP Event Package as defined in RFC 3265 [3]. The event package name is "management-request". This value appears in the Event header field present in SUBSCRIBE and NOTIFY requests for this package. 4.2. Event Package Parameters This event package does not define any event package parameters. 4.3. SUBSCRIBE Bodies The SUBSCRIBE request SHOULD contain a body. The message body, if present, will communicate the set of management protocols which are supported by the managed device, using the content type "application/ mgmt-protos-list" described below in Section 5. In the absence of a SUBSCRIBE body, the content types listed in "Accept" header MUST implicitly describe particular management protocols. If the SUBSCRIBE message body is of type "application/ mgmt-protos-list", the "Accept" header may be omitted, and the subsequent NOTIFY messages will contain "application/ mgmt-protos-list" content. 4.4. Subscription Duration Subscriptions to this event package MAY range from minutes to days. Subscriptions in hours are more typical and are RECOMMENDED, so that a lost subscription is detected within a reasonable amount of time. Since this event package is intended to allow the device to be managed, the subscription SHOULD be refreshed and maintained while the device is active and expecting to be managed. The default expiration time for subscriptions within this event package is one hour. 4.5. NOTIFY Bodies The NOTIFY request messages will contain bodies that are appropriate Littlefield Expires December 17, 2006 [Page 5] Internet-Draft SIP Management Request Event Package June 2006 to specific management protocols, as indicated by the "Accept" headers in the SUBSCRIBE message. A common body type ("application/ mgmt-protos-list") for use with multiple protocols is specified below in Section 5. If the "Accept" header is omitted, the "&doc-type" type is assumed. 4.6. Subscriber Generation of SUBSCRIBE Requests The request URI of the SUBSCRIBE request SHOULD be formed exactly as "Device URIs" are formed according to the SIP UA profile delivery framework [4], section 7.13.1. Similarly the same URI discovery process, as defined in section 8.1.2 of that document, SHOULD be used to discover the host portion of the request URI and the destination addressing of the message, with the difference that in step 3, instead of prepending the label "sipuaconfig" to domain name in the request URI, the label "sipmgmtrequest" should be prepended instead. The To and From headers will typically contain the same URI as is used in the SUBSCRIBE request. When the device knows it is shutting down or will become unreachable, the device SHOULD unsubscribe by sending a SUBSCRIBE message with an "Expires" header value of "0". 4.7. Notifier Processing of SUBSCRIBE Requests The general rules for notifier processing of SUBSCRIBE requests, as specified in RFC 3265 [3] apply. On receipt of a SUBSCRIBE message with the "management-request" event type, the notifier SHOULD authenticate the request. The notifier does not support any of the content-types specified in the "Accept" header of the SUBSCRIBE request, or if the SUBSCRIBE request message omitted the "Accept" header and did not provide a message body of type "&doc-type", the subscription SHOULD be rejected. The notifier MAY limit the duration of the subscription to an administratively configured period of time, as described in RFC 3265 [3]. 4.8. Notifier Generation of NOTIFY Requests In accordance with RFC 3265 [3], the notifier MUST send a NOTIFY message immediately upon successfully accepting or refreshing a subscription. If a management session is not desired at that time, the NOTIFY message MUST contain an empty body, indicating that this NOTIFY simply confirms the successful subscription and has no further meaning. Littlefield Expires December 17, 2006 [Page 6] Internet-Draft SIP Management Request Event Package June 2006 When a management session with the managed device is desired (the mechanism for communicating this to the notifier is outside the scope of this specification), the notifier will form a NOTIFY request containing a message body appropriate to the acceptable types determined from the SUBSCRIBE request. The NOTIFY message body will indicate, either implicitly or explicitly, through the content-type, the desired management protocol for the device to use when establishing a management session. The notifier MAY send a NOTIFY with an "Expires" header value of "0" and a "Subscription-State" header value of "terminated" to end the subscription in the event of shutdown. When TLS is used, the notifier SHOULD send the NOTIFY message over the same TLS connection as the SUBSCRIBE request came in on. 4.9. Subscriber Processing of NOTIFY Requests The general rules for subscriber processing of NOTIFY requests, as specified in RFC 3265 [3] apply. Upon receipt of a valid NOTIFY request, the subscriber should evaluate the message body. If the NOTIFY message body is empty, as will be the case for the initial NOTIFY following a new or refreshed subscription, no further action is required. Otherwise the subscriber MUST immediately attempt to establish a management session according to the mechanism and protocol indicated by the message body. Considerations of whether a subscriber should attempt to establish multiple, parallel management sessions with the same management station are beyond the scope of this specification, and should be defined for each specific management protocol as appropriate. 4.10. Handling of Forked Requests This event package does not allow forked requests to install multiple subscriptions. The techniques of RFC 3265 [3] section 4.4.9 must be used to prevent establishment of multiple subscriptions due to forking. 4.11. Rate of Notifications A notifier SHOULD implement a method to hold or otherwise avoid sending non-empty NOTIFY requests more frequently than some administratively-specified time interval. A NOTIFY request in this event package indicates the desire to establish a management session, which may impose some overhead on both the managed device and the management station. In some cases, all management sessions from the managed device will be established with the same pre-configured Littlefield Expires December 17, 2006 [Page 7] Internet-Draft SIP Management Request Event Package June 2006 management station, further reducing the value of frequent notifications. The NOTIFIER SHOULD apply rate limits that are appropriate for the connection mechanisms of the management protocols being used. 4.12. State Agents State agents are not applicable to this event package. 4.13. Examples of Usage Client NAT/NATP/Firewall Mgmt Station | | | |----------SIP SUBSCRIBE--------->| | | | |<------------200 OK--------------| | | | |<------SIP NOTIFY (empty)--------| | | | |-------------200 OK------------->| | | | . . . . |<-----SIP NOTIFY (snmp-ssh)------| | | | |-------------200 OK------------->| | | | | | | |-----------SSH connect---------->| | | | |<==========SSH session==========>| | | | | | | |<--------SNMP GetRequest---------| | | | |--------SNMP GetResponse-------->| | | | |<--------SNMP SetRequest---------| | | | |--------SNMP SetResponse-------->| | | | |<--------SSH disconnect----------| | | | [[Comment.1: This section requires significant expansion, including accurate illustrations of message content.]] Littlefield Expires December 17, 2006 [Page 8] Internet-Draft SIP Management Request Event Package June 2006 5. Management Protocol List Documents [[Comment.2: This document structure needs to be defined. It is anticipated to contain an ordered list of management protocols, where each management protocol may be composed of a protocol part and a transport part, such as "snmp-udp", "snmp-ssh", "snmp-tls", or "snmp- tcp". Consideration must be given to whether or not an existing protocol name registry can be used, or a new IANA registry must be created.]] 6. Security Considerations The intent of this event package is to enable establishment of management sessions. The security aspects of the management session itself are beyond the scope of this specification, but must be strongly considered when this event package is used. Mutual authentication of the resulting management session SHOULD be provided, though this depends on the authorization policies of both the managed device and the management station, and the operations that will be allowed. The security concerns of this event package itself depend to some extent on its use. In a scenario where the NOTIFY does not contain any information about which management station to contact, as is true for the NOTIFY message body content-type defined in this document, a forged or altered NOTIFY message will result in directing the managed device to an attacker for establishment of a management session. However, a form of denial of service (DOS) attack may result of the managed device does not rate limit its own attempts to establish management sessions. The authenticity of the NOTIFY source, and, in the case of NOTIFY message bodies which direct the managed device to a particular management server, the NOTIFY message body, SHOULD be ensured by use of appropriate end-to-end or hop-by-hop security mechanisms defined in RFC 3261 [2]. 7. IANA Considerations 7.1. SIP Event Package Registration for "management-request" Package name: message-summary Littlefield Expires December 17, 2006 [Page 9] Internet-Draft SIP Management Request Event Package June 2006 Package or Template: package Contact: Joshua Littlefield, joshl@cisco.com Published Document: [This document] 7.2. MIME Registration for "application/mgmt-protos-list" MIME media type name: application MIME subtype name: mgmt-protos-list Required parameters: none Optional parameters: none Encoding considerations: This type is only defined for transfer via SIP [2]. Security considerations: none Interoperability considerations: none Published specification: [This document] Applications which use this media: The mgmt-protos-list application subtype supports the exchange of supported and desired management protocol names between managed SIP devices and management stations. Additional information: 1. Magic number(s): N/A 2. File extension(s): N/A 3. Macintosh file type code: N/A 8. Normative Referneces [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-08.txt (work in progress), March 2006. Littlefield Expires December 17, 2006 [Page 10] Internet-Draft SIP Management Request Event Package June 2006 Author's Address Josh Littlefield Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978-936-1379 Email: joshl@cisco.com Littlefield Expires December 17, 2006 [Page 11] Internet-Draft SIP Management Request Event Package June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Littlefield Expires December 17, 2006 [Page 12]