P2PSIP Working Group H. Song Internet-Draft X. Jiang Intended status: Standards Track Huawei Expires: July 25, 2009 January 21, 2009 Diagnose P2PSIP Overlay Network draft-ietf-p2psip-diagnostics-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes P2PSIP diagnostics. It describes the usage scenarios and defines several simple methods for the diagnostics in P2PSIP overlay network. It also describes types of diagnostic information which are useful for the connection and node status monitoring. The methods and message formats are specified as extensions to P2PSIP base protocol RELOAD. Song & Jiang Expires July 25, 2009 [Page 1] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Functions . . . . . . . . . . . . . . . . . . . . 5 5. Packets Formats . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Message Codes . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Message payloads . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. diagnostics information . . . . . . . . . . . . . . . 8 6. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Inspect . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Path_Track . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Echo . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 13. Intellectual Property Statement . . . . . . . . . . . . . . . 21 Song & Jiang Expires July 25, 2009 [Page 2] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 1. Introduction P2P systems are self-organizing and ideally require no network management in the traditional sense to set up and to configure individual P2P nodes. P2P service providers may however contemplate usage scenarios where some monitoring and diagnostics are required. We present a simple connectivity test and some useful diagnostic information that may be used in such diagnostics. 1.1. Usage Scenarios The common usage scenarios for P2P diagnostics can be broadly categorized in three classes: a. Automatic diagnostics built into the P2P overlay routing protocol. Nodes perform periodic checks of known neighbors and remove those nodes from the routing tables that fail to respond to connectivity checks [Handling_Churn_in_a_DHT]. The unresponsive nodes may however be only temporarily disabled due to some local cryptographic processing overload, disk processing overload or link overload. It is therefore useful to repeat the connectivity checks to see if such nodes have recovered and can be again placed in the routing tables. This process is known as 'failed node recovery' and it can be optimized as described in the paper "Handling Churn in a DHT" [Handling_Churn_in_a_DHT]. b. P2P system diagnostics to check the overall health of the P2P overlay network, the consumption of network bandwidth, problem links and also checks for abusive or malicious nodes. This is not a trivial problem and has been studied in detail for content and streaming P2P overlays, such as for example in [Diagnostic_Framework]. Similar work has been reported more recently for P2PSIP overlays as applied to the P2PP protocol [Diagnostics_and_NAT_traversal_in_P2PP]. c. Diagnostics for a particular node to follow up an individual user complaint. In this case a technical support person may use a desktop sharing application with the permission of the user to determine remotely the health and possible problems with the malfunctioning node. Part of the remote diagnostics may consist of simple connectivity tests with other nodes in the P2PSIP overlay. The simple connectivity tests are not dependent on the type of P2PSIP overlay and they are the topic of this memo. Note however that other tests may be required as well, such as checking the health and performance of the user's computer or mobile device and also checking the link bandwidth connecting the user to the Internet. Song & Jiang Expires July 25, 2009 [Page 3] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 2. Terminology The concepts used in this document are compatible with "Concepts and Terminology for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and the P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base]. 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 [RFC2119]. 3. Motivation In the last few years, overlay networks have rapidly evolved and emerged as a promising platform to deploy new applications and services in the Internet. One of the reasons overlay networks are seen as an excellent platform for large scale distributed systems is their resilience in the presence of failures. This resilience has three aspects: data replication, routing recovery, and static resilience. Routing recovery algorithms are used to repopulate the routing table with live nodes when failures are detected. Static resilience measures the extent to which an overlay can route around failures even before the recovery algorithm repairs the routing table. Both routing recovery and static resilience relies on accurate and timely detection of failures. As described in "Security requirements in P2PSIP" [I-D.matuszewski-p2psip-security-requirement], there are some malfunctioning or badly behaving peers in P2PSIP overlay, those peers may be disabled peers, congested peers or peers behaving with misrouting, and the impact of those peers in the overlay network is degradation of quality of service provided collectively by the peers in the overlay network or interruption of those services. It is desirable to identify malfunctioning or badly behaving peers through some diagnostics tools, and exclude or reject them from the P2PSIP system. Besides those faults, node failures may be caused by underlying failures, for example, when the IP layer routing failover speed after link failures is very slow, then the recovery from the incorrect overlay topology may also be slow. Moreover, if a backbone link fails and the failover is slow, the network may be partitioned, which may lead to partitions of overlay topologies and inconsistent routing results between different partitioned components. Some keep-alive algorithms based on periodically probe and acknowledge enable accurate and timely detection of failures of one peer's neighbors [Overlay-Failure-Detection], but those algorithms only can detect the disabled neighbors using the periodical method, it may not be enough for operating the overlay network by service Song & Jiang Expires July 25, 2009 [Page 4] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 providers. One general P2PSIP overlay diagnostics protocol supporting periodical method and on-demand method for node failures and network failures is desirable. This document describes one general P2PSIP overlay diagnostics protocol useful for P2PSIP base protocol and it is a good match for some keep-alive algorithms in the P2P or P2PSIP overlay itself. 4. Overview of Functions As a diagnostics protocol, P2PSIP diagnostics protocol is mainly used to detect and localize failures or monitor performance in P2PSIP overlay network. It provides mechanisms to detect and localize malfunctioning or badly behaving peers including disabled peers, congested peers and misrouting peers. It provides a mechanism to detect direct connectivity or connectivity to the specified peer, a mechanism to detect availabilities of specified resource records and a mechanism to discover P2PSIP overlay topology and the underlay topology failures. The P2PSIP diagnostics protocol defines Inspect and Path_Track methods for connection quality check and retrieval of diagnostic information, as well as Echo method for efficient diagnostics in the administrative overlay and the Error response to these methods. Essentially it reuses P2PSIP base protocol specification and then introduces the new diagnostics methods. P2PSIP diagnostics protocol strictly follows the P2PSIP base protocol specification on the messages routing, transporting and NAT traversal etc. The diagnostic methods are however P2PSIP protocol independent. In this document, we mainly describe how to detect and localize those failures including disabled peers, congested peers, misrouting behaviors and underlying network faults in P2PSIP overlay network through a simple and efficient mechanism. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC792]) is used for connectivity checks, and traceroute is used for hop-by- hop fault localization as well as path tracing. This document specifies a "ping" mode (by defining the Inspect method) and a "traceroute" mode (implemented differently with trusted overlays such as operator deployed P2PSIP overlays, compared with untrusted overlays) for diagnosing P2PSIP overlay network. An Inspect request message is forwarded by the intermediate peers along the path and then terminated by the responsible peer, and after optional local diagnostics, the responsible peer returns an Inspect response message. If an error is found when routing, an Error Song & Jiang Expires July 25, 2009 [Page 5] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 response is sent to the initiator node by the intermediate peer. In "Traceroute" mode, we classify the diagnostics into two application scenarios. (1) In trusted p2p overlays, we use an Echo request message, it is received and disposed by each peer along the routing path, and each peer along the path returns an Echo response message with optional local diagnostics information including the result and causes if existing. (2) In untrusted p2p overlays, we define a simple Path_Track method for retrieving diagnostics information iteratively. First, the initiating node asks its neighbor A which is the next hop node to the destination ID, and then retrieve the next hop node B information, along with optional diagnostic information of A, to the initiator node. Then the initiator node asks the next hop node B(directly or symmetric routing) to get the further next hop node C information and diagnostic information of B. This step can be iterative until the request reaches responsible node D for the destination ID, and retrieve diagnostic information of node D, or terminates by some failures that prevent the process. One approach these tools can be used is to detect the connectivity to the specified peer or the availability of the specified resource- record through P2PSIP Inspect operation once the overlay network receives some alarms about overlay service degradation or interruption, if the Inspect fails, one can then send a P2PSIP Traceroute(iterative Path_Track or Echo) to determine where the fault lies. The diagnostic information MUST be only provided to authorized peers. Some diagnostic information can be authorized to all the participants in the P2PSIP overlay, and some other diagnostic information can only be provided to the authorization peer list of each diagnostic information according to the local or overlay policy. The authorization mainly depends on the kinds of the diagnostic information and the administrative considerations. 5. Packets Formats This document extends the P2PSIP base protocol to carry diagnostics information. Considering special usage of diagnostics, this document defines three simple methods Inspect, Path_Track and Echo, as well as related Error codes and some useful diagnostics information. As described in the P2PSIP base protocol, each message has three Song & Jiang Expires July 25, 2009 [Page 6] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 parts. This specification is consistent with the format. +-------------------------+ | Forwarding Header | +-------------------------+ | Message Contents | +-------------------------+ | Signature | +-------------------------+ 5.1. Message Codes The mechanism defined in this document follows P2PSIP base protocol specification, the new request and response message use the message format specified in P2PSIP base protocol messages. Different types of messages convey different message contents following the forwarding header according to the protocol design. Please refer to P2PSIP base protocol [I-D.ietf-p2psip-base] for the detailed format of forwarding header. This document reuses the Error response in the base protocol and defines new Error codes to carry different failure reports to the initiator node when failure is detected during diagnostics. Name Message Code Error 0xFFFF This document introduces three types of message: Name Message Code Inspect request 29 Inspect response 30 Path_Track request 31 Path_Track response 32 Echo request 33 Echo response 34 The final message code will be assigned by IANA as specified in section 14.4 of [I-D.ietf-p2psip-base]. 5.2. Message payloads As an extension to P2PSIP base protocol, a P2PSIP diagnostics protocol message content contains one message code following by its payloads. Please refer to P2PSIP base protocol [I-D.ietf-p2psip-base] for the detailed format of Message Contents. In addition to the newly introduced methods, this document extends Song & Jiang Expires July 25, 2009 [Page 7] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 the Error codes defined in P2PSIP base protocol specification. 5.2.1. Error Codes This document extends the Error response method defined in the P2PSIP base protocol specification to describe the result of diagnostics. This document introduces new Error Codes as below: Code Value Error Code Name 8 Underlay Destination Unreachable 9 Underlay Time exceeded 10 Message Expired 11 Upstream Misrouting 12 Loop detected 13 TTL hops exceeded The final error codes will be assigned by IANA as specified in section 14.5 of the p2psip base protocol [I-D.ietf-p2psip-base]. This document introduces several types of error information in the error_info field for Error Code 8 as an example: error_info: net unreachable host unreachable protocol unreachable port unreachable fragmentation needed source route failed Editor note: We may need more discussion here to see if we need to define an additional sub-code field for the error information. Sub- code is easier for the machine to process while various text is comfortable for a man to read. 5.2.2. diagnostics information This document introduces some new diagnostics information conveyed in the message payload, including: the number of hops that the message traverses, the underlay TTL specified, the timestamp of initiating the request message, the timestamp of receiving the request message, and the expiration time of the request message, the processing power, the bandwidth, the number of entries in one's neighbor table, etc. They are defined as below. Additional diagnostic information have been proposed in section 9 of the p2psip base protocol [I-D.ietf-p2psip-base]. Song & Jiang Expires July 25, 2009 [Page 8] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 HopCounter (8 bits): This byte only appears in diagnostic responses. It must be exactly copied from the TTL field of the forwarding header in the received request. Then this information is sent back to the request initiator to compute the hops that the message traverses in the overlay. UnderlayTTL (8 bits): It indicates the underlay TTL which the intermediate peer must adopt when forwarding the diagnostic requests, it is specified by the initiator. If the value is 0, then the intermediate peer must ignore this field, and use the underlay TTL with its local configuration. TimestampInitiated (64 bits): The time-of-day (in seconds and microseconds, according to the sender's clock) in NTP timestamp format [RFC4330] when the P2PSIP Overlay diagnostic request is sent. It can be carried in the diagnostic response message from the receiver; certainly it first appears in the diagnostic request message; TimestampReceived (64 bits): it is in a diagnostic response message as the time-of-day (according to the receiver's clock) in NTP timestamp format [RFC4330] that corresponds to the time that the P2PSIP Overlay diagnostic request was received; Expiration(64 bits): the expiration time of the request message, it is the time-of-day in NTP timestamp format [RFC4330]. It can be used to mitigate the replay attack to the destination peer and overlay network. ProcessPower (32 bits): A single value element containing an unsigned 32-bit integer specifying the processing power of the node in unit of MIPS. Bandwidth (32 bits): A single value element containing an unsigned 32-bit integer specifying the bandwidth of the node in unit of Kbps. Editor's note: For the diagnostic information of processing power, bandwidth and etc., we should look at what has been useful for PlanetLab in this context, and further discussion is needed on what mature diagnostics information for p2p overlays can be brought here. Routing_Table_Size (32 bits): A single value element containing an unsigned 32-bit integer representing the number of peers in the peer's routing table. The administrator of the overlay may be interested in statistics of this value for the consideration such as routing efficiency. Song & Jiang Expires July 25, 2009 [Page 9] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 StatusInfo (8 bits): A single value element containing an unsigned byte representing whether or not the node is in congestion status. 6. Message All P2PSIP base protocol requests and responses use the common forwarding header followed by the message contents. This document defines Inspect and Path_Track methods, and introduces the new Echo message to detect and localize failures in P2PSIP overlay network. The Error Codes to these requests are defined in section 5.2.1 of this spec. 6.1. Inspect In P2PSIP base protocol, Ping is used to test connectivity along a path. However, connectivity quality can not be measured well without some useful information, such as the timestamp and HopCounter. Here we define a new method Inspect for connectivity quality check purposes. See below for the Inspect formats. Inspect Request: struct { uint8 UnderlayTTL; uint64 TimestampInitiated; uint64 Expiration; } InspectReq; Inspect Response: struct { uint8 HopCounter; uint64 TimestampReceived; uint64 Expiration; }InspectAns; Any intermediate node which receives the Inspect request must adopt the UnderlayTTL for the next hop forwarding. If the value equals to 0, the intermediate peer must ignore this value and determine the underlay TTL using local configuration. The requirement here is that one may want to limit each hop underlay TTL from the initiator to the destination, if the underlay TTL expires somewhere, one may think that the link there is not of good quality. Each intermediate peer receiving the Inspect request/response should check the Expiration value (NTP format) to determine if the message expired. If the message expired, the intermediate peer should generate a "Message Expired" Error to the initiator node, and discard Song & Jiang Expires July 25, 2009 [Page 10] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 the message. The responsible node for the request or response MUST check this value to determine if this message should be ignored. The responsible peer of the Inspect request must exactly copy the TTL field value in the forwarding header to the HopCounter value in the response, and meanwhile, it should generate a NTP format timestamp to indicate the received time. The initiator node, as well as the responding peer, may compute the overlay One-Way-Delay time through the value in TimestampReceived and the TimestampInitiated field. However, for a single hop measurement, the traditional measurement methods must be used instead of the overlay layer diagnostics methods. Editor note: We need more discussion and careful consideration on how to use the timestamp here because time synchronization is a barrier in open Internet environment, while in the operator's network, it is not so tricky. The initiator node receiving the Inspect response must check the HopCounter field and compute the overlay hops to the destination peer for the statistics of connectivity quality from the perspective of overlay hops. Inspect is also used to detect possible failures in the specified path of P2PSIP overlay network. If disabled peers, misrouting behavior and underlying network faults are detected during the routing process, the Error responses with Error codes and descriptions, must be sent to the initiator node immediately. See section 6.4 for the details. 6.2. Path_Track We define a simple Path_Track method to retrieve the diagnostic information from the intermediate peers along the routing path. At each step of the Path_Track request, the responsible peer responds to the initiator node with the status information of itself whether or not congested , its processing power, its available bandwidth, the number of entries in its neighbor table, its uptime, his identity and network address information, and the next hop peer information. Song & Jiang Expires July 25, 2009 [Page 11] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 Peer-1 Peer-2 Peer-3 Peer-4 | | | | |(1).Path_Track Req | | | |------------------->| | | |(2).Path_Track ans | | | |<-------------------| | | | |(3).Path_Track Req | | |--------------------|------------------->| | | |(4).Path_Track Ans | | |<-------------------|--------------------| | | | |(5).Path_Track Req | |--------------------|--------------------|------------------->| | | |(6).Path_Track Ans | |<-------------------|--------------------|--------------------| | | | | Path_Track example A Path_Track request must specify which diagnostic information is requested by setting different bits in the flag contained in the Path_Track request payload. If the flag is clear, then the Path_Track request is only used for asking the next hop information, in this case the iterative mode of Path_Track is used only for checking the liveness of the peers along the routing path. The Path_Track request can be routed directly or through the overlay based on the local policy of the initiator node. Path_Track request: struct { Destination destination; Uint32 dFlags; uint64 Expiration; } RathTrackReq; destination : The destination which the requester is interested in. This may be any valid destination object, including a Node-ID, compressed ids, or Resource-ID. dFlags : An unsigned 32-bit integer indicating which kind of diagnostic information the initiator interested in. The initiator sets different bits to retrieve different kinds of diagnostic information. If dFlags is clear, then no diagnostic information is conveyed in the Path_Track response. If dFlag is set to 0xFFFFFFFF, then all diagnostic information kinds are requested. The kinds of diagnostic information including: status information, its processing power, its available bandwidth, the number of entries in its neighbor table, its uptime, etc. The mapping between the bits in the dFlags and the diagnostic information kind Song & Jiang Expires July 25, 2009 [Page 12] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 is as below: StatusInfo Flag(0x0001) : if set, the status information of the responding peer is requested; Routing_Table_Size Flag(0x0002) : if set, the number of entries in the responding peer's neighbor is requested; ProcessPower Flag(0x0004) : if set, the processing power information of the responding peer is requested; Bandwidth Flag(0x0008) : if set, the bandwidth information of the responding peer is requested; [TODO: The bits in the dFlags should also map to the diagnostic information defined in section 9 of p2psip base draft.] A response to a successful PathTrackReq is a PathTrackAns message. There is a general diagnostic information part based on the flags. Path_Track response: struct { Destination next_hop; Diagnostic_Info diag_info_list<0..2^5-1>; uint64 Expiration; } RathTrackAns; next_hop : The information of the next hop node from the responding intermediate peer to the destination node. If the responding peer is the responsible peer for the destination ID, then the next_hop node ID equals the responding node ID, and after that the initiator must stop the iterative process. diag_info_list: The diagnostic information from the responding peer. The TLV structure for Diagnostic_Info is as the following: struct { uint8 Kind-ID; uint8 length; Opaque diagnosic_information<0..2^8-1>; } Diagnostic_Info; Various kinds of diagnostic information can be retrieved, some of them are defined in this document, and some of them are defined in the p2psip base draft. This document introduces additional three new data kind-IDs as below: Song & Jiang Expires July 25, 2009 [Page 13] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 Kind Kind-ID StatusInfo 16 ProcessPower 17 Bandwidth 18 The final kind-IDs will be assigned by IANA as specified in section 14.2 of the p2psip base protocol [I-D.ietf-p2psip-base]. As for the Path_Track responses, whether or not sending back certain kind of diagnostic information to the initiator node depends on (1) the dFlags (2)the authorization policy. Failures may be detected during the process, after that an Error response should be reported to the initiator node immediately. 6.3. Echo An Echo request message is used to retrieve the diagnostic information of the specified path in administrative p2p overlays where all the peers in the overlay are trusted or based on specific authorization. For example, it can be used in a p2p overlay where all peers deployed by the operator to provide services to the customers(clients), where the diagnostics happens between peers in the p2p overlay. For the untrusted p2p overlays, e.g. some end user equipments can be the peers in the overlay network, then the Echo method must be used with care for the consideration of potential DoS attack. Compared with Path_Track method, Echo method brings less messages to the p2p overlay network. [Editor's note: More consideration needs to be given to the security of Echo method and also complexity of the method if any.] An Echo request is normal P2PSIP base protocol message; it can be initiated by any node in the administrative p2p overlay which supports P2PSIP base protocol specification. An Echo request must specify which diagnostic information it is interested in by setting different bits in the dFlags contained in the request payload. If all diagnostic flags are clear, the response is a simple Echo response containing no additional diagnostic information. Any intermediate peer along the Echo request path should forward the Echo request to the next hop, and then returns an Echo response to the initiator node, along with the diagnostic information indicated Song & Jiang Expires July 25, 2009 [Page 14] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 by the dFlags in the Echo request. As for the Echo responses, whether or not sending back certain kind of diagnostic information to the initiator node depends on (1) the dFlags (2)the authorization policy. Any Echo request/response whose time in the Expiration field expired should be ignored. Peer-1 Peer-2 Peer-3 Peer-4 | | | | | (1).Echo Request | | | |------------------->| | | | | (2).Echo Request | | | |------------------->| | | (3).Echo Response | | | |<-------------------| | | | | | (4).Echo Request | | | |------------------->| | | (5).Echo Response | | |<-------------------|--------------------| | | | | (6).Echo Response | |<-------------------|--------------------|--------------------| | | | | P2PSIP Echo example Echo request: Struct { Uint32 dFlags; uint64 Expiration; }EchoReq dFlags (32 bits): An unsigned 16-bit integer indicating which kind of diagnostic information the initiator interested in. The initiator sets different bits to retrieve different kinds of diagnostic information. If dFlags is clear, then no diagnostic information is conveyed in the Echo response. See section 6.2 for the mapping between the bits in the dFlags and the diagnostic information kinds. Expiration: See section 5.2.2 for the meaning. Song & Jiang Expires July 25, 2009 [Page 15] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 Echo response: Struct { Diagnostic_Info diag_info_list<0..2^5-1>; uint64 Expiration; }EchoAns The peer may find misrouting behaviors or the underlay failures during the Echo process, then an Error response should be generated and send back to the initiator node. See section 6.4 for details. 6.4. Error responses In p2psip overlay, the error response can be generated by the intermediate peer or responsible peer, to a diagnostic message or other messages. All error responses contain the Error code followed by the subcode and descriptions if existed. When a request arrives at a peer, if the peer's responsible ID space does not cover the destination ID of the request, then the peer continues to forward this request according to the overlay specified routing mode. When a request arrives at a peer, the peer may find some connectivity failures or malfunction peers through the analysis of via list or underlay error messages. The peer should report the error responses to the initiator node. The malfunction node information should also be reported to the initiator node in the error message payload. The peer should return an Error response with the Error Code 8 "Underlay Destination Unreachable" when it receives an ICMP message with "Destination Unreachable" information after forwarding the received request. The peer should return an Error response with the Error Code 9 "Underlay Time Exceeded" when it receives an ICMP message with "Time Exceeded" information after forwarding the received request. The peer should return an Error response with the Error Code 10 "Message Expired" when it finds that the message expires the time field Expiration contained in the message payload. The peer should return an Error response with Error Code 11 "Upstream Misrouting" when it finds its upstream peer disobeys the routing rules defined in the overlay. The immediate upstream peer information should also be conveyed to the initiator node. The peer should return an Error response with Error Code 12 "Loop detected" when it finds a loop through the analysis of via list. Song & Jiang Expires July 25, 2009 [Page 16] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 The peer should return an Error response with Error Code 13 "TTL hops exceeded" when it finds that the TTL field value is no more than 0 when forwarding. 7. Security Considerations The Echo method may potentially cause DoS attack to the initiator, though this implementation is more efficient than using iterative mode of Path_Track operation. An advice is to use the efficient Echo operation in administrated P2PSIP overlay and use the pacing-style Path_Track operation in the untrustworthy P2PSIP overlay network, certainly, the probability of this type of DoS attack is very low because the overlay is distributed and then it is very hard for the attacker to know the accurate Peer-IDs and attack most of all peers simultaneously. 8. IANA Considerations Message Code: this document introduces three new type of message to the "RELOAD Message Code" Registry as below: +-------------------+----------------+----------+ | Message Code Name | Code Value | RFC | +-------------------+----------------+----------+ | inspect_req | 29 | RFC-AAAA | | inspect_ans | 30 | RFC-AAAA | | path_track_req | 31 | RFC-AAAA | | path_track_ans | 32 | RFC-AAAA | | echo_req | 33 | RFC-AAAA | | echo_ans | 34 | RFC-AAAA | +-------------------+----------------+----------+ Error Code: this document introduces some new Error Codes to the "RELOAD Message Code" Registry as below: Code Value Error Code Name 8 Underlay Destination Unreachable 9 Underlay Time exceeded 10 Message Expired 11 Upstream Misrouting 12 Loop detected 13 TTL hops exceeded Data Kind-ID: This document introduces additional data kind-IDs to the "RELOAD Data Kind-ID" Registry as below: Song & Jiang Expires July 25, 2009 [Page 17] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 Kind Kind-ID StatusInfo 16 ProcessPower 17 Bandwidth 18 9. Acknowledgments We would like to thank Zheng Hewen for the contribution of the initial version of this draft. We would also like to thank Bruce Lowekamp, Salman Baset, Henning Schulzrinne, Roni Even and Jiang Haifeng for the email discussion and their valued comments, and thank Henry Sinnreich for contributing to the usage scenarios in the Introduction. The authors would also like to thank the many people of the IETF P2PSIP WG that have contributed to discussions and provided input invaluable in assembling this document. 10. References 10.1. Normative References [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January . [RFC4981] Risson, J., "Survey of Research towards Robust Peer-to- Peer Networks: Search Methods", September 2007. [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft-ietf-p2psip-sip-00 (work in progress), October 2008. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Song & Jiang Expires July 25, 2009 [Page 18] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-01 (work in progress), December 2008. [I-D.song-p2psip-security-eval] Yongchao, S., Zhao, B., Jiang, X., and J. Haifeng, "P2PSIP Security Analysis and Evaluation", draft-song-p2psip-security-eval-00 (work in progress), February 2008. [I-D.bryan-p2psip-app-scenarios] Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins, "Application Scenarios for Peer-to-Peer Session Initiation Protocol (P2PSIP)", draft-bryan-p2psip-app-scenarios-00 (work in progress), November 2007. [I-D.bryan-p2psip-requirements] Bryan, D., "P2PSIP Protocol Framework and Requirements", draft-bryan-p2psip-requirements-00 (work in progress), July 2007. [I-D.zheng-p2psip-diagnose] Song, H. and X. Jiang, "Diagnose P2PSIP Overlay Network", draft-zheng-p2psip-diagnose-04 (work in progress), December 2008. [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-02 (work in progress), June 2007. [Overlay-Failure-Detection] Zhuang, S., "On failure detection algorithms in overlay networks", Proc. IEEE Infocomm, Mar 2005. [Handling_Churn_in_a_DHT] Rhea, S., "Handling Churn in a DHT", USENIX Annual Conference, June 2004. [Diagnostic_Framework] Jin, X., "A Diagnostic Framework for Peer-to-Peer Streaming", 2005. [Diagnostics_and_NAT_traversal_in_P2PP] Gupta, G., "Diagnostics and NAT Traversal in P2PP - Design and Implementation", Columbia University Report , June 2008. Song & Jiang Expires July 25, 2009 [Page 19] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 10.2. Informative References [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., and C. Huitema, "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", draft-ietf-behave-turn-04 (work in progress), Junly 2007. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-17 (work in progress), July 2007. [I-D.baset-p2psip-p2pp] Baset, S., "Peer-to-Peer Protocol (P2PP)", draft-baset-p2psip-p2pp-00 (work in progress), July 2007. [I-D.matuszewski-p2psip-security-requirement] Song, H., York, D., and M. Matuszewski, "Security requirements in P2PSIP", draft-matuszewski-p2psip-security-requirements-04 (work in progress), November 2008. 11. Authors' Addresses Song Haibin Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565867 Fax: +86-25-84565888 Email: melodysong@huawei.com Jiang Xingfeng Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565868 Fax: +86-25-84565888 Email: jiang.x.f@huawei.com Song & Jiang Expires July 25, 2009 [Page 20] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 12. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Intellectual Property Statement The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into Song & Jiang Expires July 25, 2009 [Page 21] Internet-Draft Diagnose P2PSIP Overlay Network January 2009 other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Song & Jiang Expires July 25, 2009 [Page 22]