P2PSIP Y. Peng Internet-Draft W. Wang Intended status: Informational Z. Hao Expires: January 12, 2012 Y. Meng ZTE Corporation July 11, 2011 An SNMP Usage for RELOAD draft-peng-p2psip-snmp-02 Abstract This document defines a SNMP Usage for REsource LOcation And Discovery(RELOAD), The SNMP Usage provides the functionality of managing the RELOAD network. The SNMP Usage provides lookup service for the network manager's address stored in the overlay. The SNMP Usage also defines the method that allow the registrations to map a network manager'name to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SNMP messages are exchanged. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Peng, et al. Expires January 12, 2012 [Page 1] Internet-Draft An SNMP Usage for RELOAD July 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Management Requirements . . . . . . . . . . . . . . . 3 4. Basic Operations and SNMP . . . . . . . . . . . . . . . . . . 4 5. Overview of SNMP Usage . . . . . . . . . . . . . . . . . . . . 4 6. Network Manager Registering . . . . . . . . . . . . . . . . . 5 7. O-Node Looks up Network Manger and Forms a Direct Connection with the Manager . . . . . . . . . . . . . . . . . 6 8. O-Node information Collection . . . . . . . . . . . . . . . . 8 9. Manager Forms a Direct Connection with O-Node . . . . . . . . 8 10. Network Manger Looks up the O-Node for a Resource . . . . . . 9 11. SNMP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 12.2. Generate Keys . . . . . . . . . . . . . . . . . . . . . . 11 12.3. Distribute Keys . . . . . . . . . . . . . . . . . . . . . 11 12.4. SNMP Message Transmission . . . . . . . . . . . . . . . . 13 12.5. Timeliness . . . . . . . . . . . . . . . . . . . . . . . 13 12.6. Update Keys . . . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Peng, et al. Expires January 12, 2012 [Page 2] Internet-Draft An SNMP Usage for RELOAD July 2011 1. Introduction This document defines an SNMP Usage for REsource LOcation And Discovery (RELOAD),which can be used to manage the RELOAD network. It can provide important network management functions, such as adjusting the network configuration, monitoring the performance of the network, collecting real-time failure information, etc. These network management functions are essential for stable operation and high-quality services of the network. As traditional network management protocols (e.g., SNMP) cannot be directly applied to RELOAD network management, it is necessary to introduce new RELOAD usage of SNMP. As defined in [I-D.ietf-p2psip-base], there are two kinds of nodes in RELOAD network: one is centralized servers, such as the Enrollment Server; the other is distributed nodes, such as Peer and Client. The management function of centralized servers can be carried out by traditional management methods, so we don't discuss the management of the centralized server in this document, and only focus on the management of the distributed nodes. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. We use the terminology and definitions from Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base Protocol [I-D.ietf-p2psip-base] extensively in this document. SNMP: Simple Network Management Protocol. Manager: Network Manager. Node: RELOAD Node, including both Peer and Client. O-Node: Objective Node, which is managed by a network manager. R-Node: Responsibility Node, which is responsible for storing the data according to P2P algorithm. 3. Network Management Requirements RELOAD network SHOULD provide management functions for RELOAD Nodes. At the same time, as the RELOAD network is a provider of resource Peng, et al. Expires January 12, 2012 [Page 3] Internet-Draft An SNMP Usage for RELOAD July 2011 location and discovery services, it SHOULD provide monitoring of the resources and its associated operation in the network as an important part of the network management. Therefore, there are two kinds of the management targets in the RELOAD network: nodes and resources. The management functions of the nodes MAY include setting node name, software version or other configuration information, monitoring the number of the messages initiated, forwarded or processed by nodes, reporting program failure , message forwarding failure or other error on nodes. The management of resources MAY include tracing forwarded the RELOAD messages or processing flows of resources. 4. Basic Operations and SNMP The management interactions between nodes can be abstracted into a few basic operations: 1). the network manager requests data of nodes and resources; 2). the network manager sets data of nodes and resources; 3). nodes initiate data reports to the network manager. A variety of management functions can be carried out by these basic operations or their combinations. This document adopts SNMP as a RELOAD Usage to achieve the management of the RELOAD network. The basic operations described above can be implemented by messages defined in SNMP, such as GetRequest, GetNextRequest, GetBulkRequest, Response, SetRequest, Trap, InformRequest. 5. Overview of SNMP Usage The network manager needs to join the RELOAD network as a peer or a client before performing management operations. In other words, the manager function is deployed on the managing node, and agent function is deployed on managed node. The manager executes management operations of the RELOAD network through the agent deployed on the managed nodes. The protocol is RELOAD between nodes, and the protocol is SNMP between manager and agent. The diagram of system composition and protocol is as follow: Peng, et al. Expires January 12, 2012 [Page 4] Internet-Draft An SNMP Usage for RELOAD July 2011 +------------------------------------------------+ | RELOAD Network | | | | | | +------------+ +------------+ | | | | SNMP | | | | | Manager |------------------| Agent | | | | | | | | | +------------+ +------------+ | | | | RELOAD | | | | | Node |------------------| Node | | | | | | | | | +------------+ +------------+ | | | +------------------------------------------------+ SNMP Usage's position in the RELOAD Architecture diagram is as follow: Application +-------+ +-------+ +-------+ | SIP | | XMPP | | SNMP | ... | Usage | | Usage | | Usage | +-------+ +-------+ +-------+ ------------------------------------------- Messaging API RELOAD 6. Network Manager Registering The Node ID of the network manager which acts as a provider of management service should be able to be found by other RELOAD nodes, thus managed nodes can send messages to the manager. The Node ID of network manager may not be fixed or predefined in advance. So a recognizable name is necessary and the managed nodes should find the Node ID of the manager through this fixed name. Therefore, it is necessary for the manager to register itself in the network after joining the network. In other words, the manager needs to store the mapping between its name and its Node ID in the RELOAD network. When a managed node wants to contact the manager, it needs to first look up the manager's Node ID corresponding to the predefined management service name. This registration is achieved by storing the name of the network manager and the structure of SnmpRegistration into the RELOAD network. The corresponding SNMP-REGISTRATION Kind-ID will be formally defined in the following chapter. It is proposed to store Peng, et al. Expires January 12, 2012 [Page 5] Internet-Draft An SNMP Usage for RELOAD July 2011 the mapping of the manager's name to a destination list in this document. Therefore, a single Node ID as a special case for a destination list. The contents of a SnmpRegistration structure are as follows: struct { opaque contact_prefs<0..2^16-1>; Destination destination_list<0..2^16-1>; } SnmpRegistrationData; struct { uint16 length; SnmpRegistrationData data; } SnmpRegistration; The contents of the SnmpRegistration PDU are: length the length of the rest of the PDU data the contents of the registration data is an opaque string containing the network manager's contact preferences and a destination list for the peer. 7. O-Node Looks up Network Manger and Forms a Direct Connection with the Manager When a target node needs to send messages to a network manager, it must check whether a connection has been established between itself and the network manager first. If the connection has been established, the target node will directly send messages to the manager. Otherwise, the target node must perform a query of the manager's Node ID, then exchanges ICE addresses with the network manager and checks connectivity and establishes connection, as shown below: Peng, et al. Expires January 12, 2012 [Page 6] Internet-Draft An SNMP Usage for RELOAD July 2011 O-Node R-Node Manager | | | | | | |FetchReq | | |---------------->| | | | | | | | |FetchAns | | |<----------------| | | | | | | | |AppAttachReq | | |-------------------------------->| | | | | | | |AppAttachAns | | |<--------------------------------| | | | | | | |ICE Check | | |<------------------------------->| | | | | | | |SNMP | | |-------------------------------->| | | | | | | | | | 1. O-Node performs a Fetch for kind SNMP-REGISTRATION at the Resource-ID corresponding to the manager's name through the overlay to get the manager's Node ID. 2. The overlay transmits the FetchReq to R-Node that is responsible for the Resource-ID corresponding to the manager's name. 3. R-Node return FetchAns with the manager's Node ID through the overlay. 4. O-Node send an AppAttachReq with the manager's ID to the network manager through the overlay. The AppAttachReq contains O-Node's candidate addresses. 5. The network manager returns an AppAttachAns to O-Node. The AppAttachAns contains the manager's candidate addresses. 6. O-Node and Network manager perform ICE check to select a pair of appropriate addresses from candidate addresses to communicate with Peng, et al. Expires January 12, 2012 [Page 7] Internet-Draft An SNMP Usage for RELOAD July 2011 each other. 7. O-Node sends SNMP messages to the network manager through the selected connection. 8. O-Node information Collection Before a network manager performs management tasks for nodes, it must first collect the Node ID and its status information of managed nodes. The way of a manager collecting the information of RELOAD nodes (including Peer and Client) is as follows: when a managed node joins the RELOAD network, it needs to get the name of a network manager from its configuration or an Enrollment Server; then this node connects to the network manager and registers its own information, such as node name, Node ID, status, etc., to the manager. The procedure of finding the manager and connecting to it has been introduced in the previous section. There are many other ways to collect information of managed nodes, which could be studied in future documents. 9. Manager Forms a Direct Connection with O-Node When a network manager needs to send a management task message to a target node, it must check whether a connection has been established between itself and the target node. If the connection has been established, the network manager will directly send the message to the target node. Otherwise the network manager must exchange ICE addresses with the target node, then checks connectivity and establishes connection, as shown below: Peng, et al. Expires January 12, 2012 [Page 8] Internet-Draft An SNMP Usage for RELOAD July 2011 Manager O-Node | | | | | | |AppAttachReq | |-------------------------------->| | | | | |AppAttachAns | |<--------------------------------| | | | | |ICE Check | |<------------------------------->| | | | | |SNMP | |-------------------------------->| | | | | | | | | 1. Network manager sends an AppAttachReq to the O-Node through the overlay. The AppAttachReq contains the manager's candidate addresses. 2. O-Node returns an AppAttachAns to the network manager through the overlay. The AppAttachAns contains the O-Node's candidate addresses. 3. Network manager and O-Node perform ICE check to select a pair of appropriate addresses from candidate addresses to communicate with each other. 4. Network manager send SNMP messages to O-Node through the selected connection. 10. Network Manger Looks up the O-Node for a Resource When a network manager needs to send a management task for resource, it is necessary that the network manager first gets the Node ID of the O-Node responsible for the resource so as to judge whether there is a connection with the O-Node. One way for the manager to get the Node ID of the O-Node responsible for the resource is to acquire the Node ID of the O-NODE responsible for the target resource through via_list of Forwarding Header in FindAns. The process is as follows: Peng, et al. Expires January 12, 2012 [Page 9] Internet-Draft An SNMP Usage for RELOAD July 2011 Firstly, the network manager sends an FindReq to the RELOAD network, the target Reource ID is put into the destination_list of the FindReq. Then the RELOAD network routes FindReq to the node responsible for the target Resource ID according to its routing algorithm. Secondly, the O-Node returns FindAns to the network manager through the RELOAD network. The first Node ID in the via_list of the Forwarding Header of the FindAns is the Node ID of the O-Node responsible for the target resource. After the network manager gets the Node ID of O-Node, it will be able to judge whether there is a connection between itself and the O-Node. If the connection exists, the network manager may directly send SNMP message to the O-Node, otherwise it is necessary to establish a new connection to the O-Node. 11. SNMP-REGISTRATION Kind Definition This section defines the SNMP-REGISTRATION kind. Name SNMP-REGISTRATION Kind ID The Resource Name for the SNMP-REGISTRATION Kind-ID is the Name of the network manager. The data stored is a SnmpRegistrationData, which can contain a destination list and contact preferences to the peer which is acting for the network manager. Data Model The data model for the SNMP-REGISTRATION Kind-ID is single value. Access Control USER-NODE-MATCH. Data stored under the SNMP-REGISTRATION kind is of type SnmpRegistration. A destination list can be used to reach the network manager. 12. Security Considerations 12.1. Overview The goals of SNMP Usage forRELOAD security are same as SNMP security [RFC3414]. 1. Provide for verification that each received SNMP message has not Peng, et al. Expires January 12, 2012 [Page 10] Internet-Draft An SNMP Usage for RELOAD July 2011 been modified during its transmission through the network. 2. Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated. 3. Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent. 4. Provide, when necessary, that the contents of each received SNMP message are protected from disclosure. There are three solutions to the security problem in SNMP Usage for RELOAD. The first option is shared key based solution, which is SNMPv3 security solution (USM). The second option is PKI based security solution, which is to use the certificate of RELOAD to authenticate and encrypt the SNMP messages. The third option is DTLS based security solution, which uses the secure DTLS links to transfer the SNMP message. Because the first option has been supported widely by the SNMPv3 devices, we recommend the first option. But it's difficult to distribute securely the keys to large numbers of agents in the SNMP security solution. In this document, we distribute the key to each agent by the certificate mechanism of RELOAD. This method will be introduced below. 12.2. Generate Keys Every user has an authentication password and an encryption password which is stored in SNMP manager. The user!_s authentication key and encryption key are generated from these passwords. Due to reduce the risk of keys leakage, SNMP security model requires to generate different localized key for each agent. The localized key is generated from concatenating user key and engine ID of the agent. The engine ID of agent can be got by the discovery process defined in SNMP USM. 12.3. Distribute Keys In order to ensure distributed keys not to be intercepted and tampered in transmission path, we use certificate provided by RELOAD to distribute keys. The process is as follows. Peng, et al. Expires January 12, 2012 [Page 11] Internet-Draft An SNMP Usage for RELOAD July 2011 +---------------------+ +-------------------+ |Manager M-Node| |Agent O-Node| C-Node +---------------------+ +-------------------+ | | | | | | +------------------+ | | | | |Generate localized| | | | | |authentication key| | | | | |and encyption key | | | | | |oftarget agent | | | | | +------------------+ | | | | | | | | | | Get certificate of O-Node | | |<------------>|<---------------------------------------->| | | | | | +----------------+ | | | | |Encrypt and hash| | | | | |localized keys | | | | | |according to PKI| | | | | |mechanism | | | | | +----------------+ | | | | | | | | | | Send localized keys message | | | |---------------------------->| | | | | | | | | | | Get certificate of M-Node | | | |<---------->|<------------>| | | | | | | |+------------------------+ | | | ||Authenticate and decrypt| | | | ||localized keys according| | | | ||to PKI mechanism | | | | |+------------------------+ | | | | | | | | | | | | | | +------------------+ | | | | |Get localized | | | | | |authentication key| | | | | |and encyption key | | | | | |of agent | | | | | +------------------+ | | | | | | | | | | | | 1. The manager generates the localized authentication key and encryption key for the SNMP agent and the user. 2. The manager needs to get the certificate of O-Node, on which the target agent resides, to encrypt the key message. So it directs Peng, et al. Expires January 12, 2012 [Page 12] Internet-Draft An SNMP Usage for RELOAD July 2011 M-Node, on which the manager resides, to get the arbitrary user!_s certificate of O-Node from the RELOAD network. 3. According to PKI mechanism, the manager encrypts the local authentication key and encryption key, and computes digest of these keys, with the certificate of O-Node and the private key of M-Node. 4. The manager sends this encrypted keys message and its digest to the target agent. The distribution message is extended SNMP message, so RELOAD certificate(4) need to be added to options of the msgSecurityModel in SNMP USM message. 5. The agent needs to get the certificate of M-Node to authenticate the key message. So it directs O-Node get the user's certificate of M-Node from the RELOAD network. 6. According to PKI mechanism, the agent authenticates and decrypts the key message with the certificate of M-Node and the private key of O-Node. 7. The agent gets its own localized authentication key and encryption key from the key message, then may do related process. 12.4. SNMP Message Transmission After the manager and the agent know their shared keys, they can protect the SNMP messages transmitted between them by using the keys. The method detail of protecting SNMP messages is defined in SNMP USM, so we won!_t describe it in this document. 12.5. Timeliness In order to protect the management messages from being delayed and replayed by malicious users, timeliness check is demanded in SNMPv3 security model. It is a kind of loose clock synchronization mechanism. We still use this mechanism to against being malicious delayed and replayed in SNMP Usage for RELOAD. 12.6. Update Keys In order to protect the keys from being disclosing, it is recommended to update local keys timely in SNMP security model, and the update mechanism is also defined. In this document, we still use the same mechanism to update keys. Peng, et al. Expires January 12, 2012 [Page 13] Internet-Draft An SNMP Usage for RELOAD July 2011 13. IANA Considerations This document has no IANA Considerations. 14. Acknowledgments This draft is based on "REsource LOcation And Discovery (RELOAD) Base Protocol" draft by C. Jennings, B. Lowekamp, E. Rescorla, S. Baset and H. Schulzrinne. This draft make a reference to "A SIP Usage for RELOAD" draft by C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. Thanks to the many people of the IETF P2PSIP WG whose many drafts we have learned. 15. References 15.1. Normative References [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)Base Protocol", August 2010. [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 15.2. Informative References [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", July 2008. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Peng, et al. Expires January 12, 2012 [Page 14] Internet-Draft An SNMP Usage for RELOAD July 2011 draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Appendix A. Additional Stuff Authors' Addresses YongLin Peng ZTE Corporation Nanjing, 210012 China Phone: +86 13776637274 Email: peng.yonglin@zte.com.cn Wei Wang ZTE Corporation Nanjing, 210012 China Phone: +86 13851658076 Email: wang.wei108@zte.com.cn ZhenWu Hao ZTE Corporation Nanjing, 210012 China Phone: +86 13382087596 Email: hao.zhenwu@zte.com.cn Peng, et al. Expires January 12, 2012 [Page 15] Internet-Draft An SNMP Usage for RELOAD July 2011 Yu Meng ZTE Corporation Nanjing, 210012 China Phone: +86 18651806839 Email: meng.yu@zte.com.cn Peng, et al. Expires January 12, 2012 [Page 16]