Steven Hessing April 2002 Internet-Draft Document: draft-hessing-p2p-messaging-00.txt Expires: October 2002 Peer to Peer Messaging Protocol (PPMP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. draft-hessing-p2p-messaging-00.txt April 2002 Abstract The Peer to Peer Messaging Protocol supports the creation of scalable, extensible and secure Peer to Peer networks leveraging current practices and introducing new concepts to P2P networking such as the support of multiple communities, security and multicasting. The protocol is highly extensible to allow for the development of additional features and applications for p2p networks. Table of Contents 1. Overview.....................................................3 2. Conventions used in this document............................4 3. Introduction.................................................4 4. Messages.....................................................5 4.1. PPMP header................................................9 4.2. Checksum header...........................................11 4.3. Message Length header.....................................12 4.4. Cease header..............................................12 4.5. Path header...............................................13 4.6. Path Record header........................................14 4.7. Connection header.........................................15 4.8. Authentication header.....................................16 4.9. Encryption header.........................................16 4.10. Error header.............................................17 5. Message forwarding..........................................18 5.1. Broadcasting..............................................19 5.2. Routed....................................................20 5.3. Fully Specified Path......................................21 5.4. Multicasting..............................................21 6. Security profiles...........................................22 6.1. Requirements for joining a community......................22 6.2. Security for the transport of messages....................23 6.2.1. Segment security.....................................23 6.2.2. Path security........................................24 6.3. Data security.............................................25 7. Connection setup and maintenance............................25 7.1. Bidirectional Connections.................................27 7.1.1. Establishing a bi-directional transport connection...27 7.1.2. Negotiate bi-directional connection parameters.......28 7.1.3. Negotiate supported forwarding mechanisms for bi- directional connections.....................................29 7.1.4. Breaking bi-directional connection collision.........30 7.1.5. Keepalive messages for bi-directional connections....31 7.2. Multicast, unidirectional connections.....................32 Hessing Individual submission - Expires October 2002 2 draft-hessing-p2p-messaging-00.txt April 2002 7.2.1. Multicast Session Announcement header................32 7.2.2. Multicast Session Report header......................33 7.2.3. Sequence header......................................34 7.2.4. Forwarding messages over multicast transport.........34 8. Communities.................................................35 8.1. Community Announcements...................................36 8.2. Community Description header..............................37 8.3. Community Authorization header............................40 9. Out-of-band Data Transport..................................40 10. Capabilities................................................41 10.1. Ping capability..........................................42 10.2. Pong capability..........................................42 10.3. Servent Discovery capability.............................42 10.4. Hello capability.........................................42 10.5. Connection Advise capability.............................43 10.6. Community Discovery capability...........................44 10.7. Community Invitation capability..........................45 10.8. XML Query capability.....................................46 10.9. XML Response capability..................................46 10.10. Resource Push Request capability........................47 10.11. Algorithm Request capability............................48 10.12. Algorithm Response capability...........................48 10.13. Dataset Request capability..............................49 10.14. Dataset Response capability.............................49 10.15. Dataset Result capability...............................50 10.16. Chat capability.........................................51 11. Network management..........................................51 12. Security considerations.....................................52 13. IANA Considerations.........................................53 14. References..................................................55 15. Author's Address............................................56 16. Full Copyright Statement....................................56 1. Overview This document describes a protocol for the exchange of messages between systems participating in a peer to peer (P2P) network. A system participating in such a network is called a servent. The protocol introduces the concepts of the addressing of servents and the forwarding of messages in the P2P network between servents using either unicast or multicast transport. The protocol supports the membership of servents of one or more communities with each community supporting one or more applications. Hessing Individual submission - Expires October 2002 3 draft-hessing-p2p-messaging-00.txt April 2002 Each application consists of a set of capabilities and a number of services provided from outside the P2P network. The protocol supports the specification of requirements for a servent to join a community and supports for authentication and encryption of messages on the P2P network both on a hop-by-hop and on an end-to-end basis. Finally the protocol references a number of unicast and multicast protocols to be used to exchange bulk data between servents without making use of the p2p network. 2. Conventions used in this document 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 [2]. 3. Introduction In a P2P network, the key elements are servents and messages. Servents send each other messages to perform functions. This protocol introduces three separate layers in such a message. The first layer provides for the addressing of servents and the forwarding of messages, the second layer provides for the security of messages while they are being transported through the p2p network and the third layer supports application functionality. Servents can only exchange messages with each other if there is a direct connection between the two servents or they have connections to other servents that can forward the message between the source and destination servent. Two servents that have a direct connection to each other are called peers. This protocol introduces to P2P technology the concept of multiple communities. A community is a group of systems that have a common goal for using P2P technology. A community is defined by its security profile and its supported applications. The security profile describes how systems can join the community and what requirements exist for the transport of messages and data between the systems in the community. Applications are a combination of a set of capabilities and zero or more services. A capability is a functionality to be performed by one or more servents. A service is some functionality that is provided by a system outside of a p2p network, without using this p2p protocol. Communities can be either well-known or dynamically created. Well- known communities are registered with IANA. Dynamically created Hessing Individual submission - Expires October 2002 4 draft-hessing-p2p-messaging-00.txt April 2002 communities are announced by servents to each other using connection management messages. There are two well-known communities defined in this document. There is the special-purpose connection management community and the network management community. Implementations of this document MUST support the former and SHOULD support the latter community, next to any other community that the implementation supports. Having servents that are members of different communities share one network management community will allow for community interaction, greater network interconnectivity and more opportunities for optimalisation of the P2P network. This protocol introduces a number of specifications for each of the three message layers. It only describes a basic set of functionalities for each of the three layers. It is anticipated that other documents will provide additional specifications and build upon the protocol foundation provided in this document. 4. Messages Messages are used when one servent (the source servent) sends information, a request or a response to another servent (the destination servent) using one of the capabilities that are supported by a community that both servents are a member of. Servents establish connections to each other using a connection setup mechanism described in the section 'Connection setup'. Two directly connected servents are called peers. When a servent sends a message to a destination servent that is not directly connected to it via intermediate servents then these other servents SHOULD forward the message until it reaches the destination servent. Sourcing or forwarding a message to a servent is only allowed if the servent that the message is being sent or forwarded to (the next-hop servent) is member of the same community as specified in the message. Messages thus belong to a community. Messages belonging to a community MUST only be send, received, forwarded and processed by servents that are member of the same community. A servent that is not a member of a community MUST never receive, send, forward or process messages from that community. A servent receiving a message belonging to a community it is not a member of MUST discard the message immediately and MUST cease the connection to the peer from which it has received the message with the cease code for 'Connection error' with the cease sub-code for 'Invalid community'. More information about cease messages can be found in the section 'Cease header'. A servent is NOT REQUIRED to forward a message it receives. If the time to live of the message is zero then the message MUST be discarded. If there is a shortage of local system resources or there is another local reason not to forward the message then the servent Hessing Individual submission - Expires October 2002 5 draft-hessing-p2p-messaging-00.txt April 2002 MAY discard the message. A servent sending a message to its destination via one or more intermediate servents MUST NOT assume that the message will be delivered to its destination. Two servents establishing a direct connection negotiate the version of the P2P protocol. Messages MUST be sent over a connection using the protocol version negotiated for that connection. If a message is received over a connection with a mismatch in the protocol version then the connection MUST be ceased with the cease code 'Connection error' and the sub-code of 'Invalid protocol version'. Messages coming in over a connection with one protocol version MAY be sent out over another connection with another protocol version. A servent performing this protocol conversion for a message which contains a checksum MUST verify and recalculate this checksum before forwarding the message. A servent SHOULD ensure that all connection management messages are sent in a timely manner to its peers. Messages MUST be sent using only the headers supported by the community and its capabilities. Messages using a capability that is not supported by the community MUST be discarded by a servent receiving the message whether that message is destined for that servent or not. The servent MUST either withdraw the community announcement to this peer with a Community Description message or cease the connection to the peer it received the message from. A cease message SHOULD in the latter case be sent to the peer with the cease code for 'Message error' and the error sub-code for 'Invalid capability'. A message is defined by the community it belongs to, the servent that has sourced it and its Message-ID. This tuple SHOULD be used to uniquely identify messages. If and when a Connection header is defined then this header SHOULD also be used to determine whether the message is a duplicate of another message it has previously received or not. Whenever a servent receives a duplicate message it SHOULD silently discard the duplicate. A servent MUST never forward a message it has received from a peer with its own Source Servent ID. A servent MAY analyze the contents of a message even it is not the destination of the message. The servent MAY use the information for network discovery, data caching or any other purpose it sees fit. There is thus no inherent or assumed privacy in a P2P network. Communities wishing to have privacy features should use the available security provisions in this P2P protocol as described in the section 'Path Security'. Hessing Individual submission - Expires October 2002 6 draft-hessing-p2p-messaging-00.txt April 2002 A message can either be directed to a single servent or broadcasted to all servents that are member of the community. A message consists of: - Required Protocol headers - Optional Protocol headers - Security headers - Capability headers - Payload Message headers MUST follow this order. A message must start with the PPMP header. This header, together with the Checksum header MUST be supported by every servent. Communities specify the requirements for any other capabilities that a servent MUST support. As support of the Connection Management community is REQUIRED for each servent, support for the capabilities defined by the Connection Management community is also REQUIRED for each servent. See the section on 'Community Announcements' on the capability support requirements for the Connection Management community. Some protocol headers are required in each message, other protocol headers can be optionally included. Whenever the description of a value of a header field is depicted as (Reserved) then this value is not available for use. All values in headers are in network byte order also known as big-endian order such that for any value consisting of n bytes this value can be collected from the byte stream by taking: value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... | byte[n-1]; The values for Message and Header length depict the length in bytes. Header Header Header type Included Header name code length in checksum? 0x0000 N/A N/A N/A (Reserved) 0x0001 0x0024 Required Partial PPMP (2) 0x0002 0x0008 Required(1) No Checksum 0x0003 0x000C Optional Yes Message Length 0x0004 0x0006 Optional Yes Cease 0x0005 Optional Yes Community Description Hessing Individual submission - Expires October 2002 7 draft-hessing-p2p-messaging-00.txt April 2002 0x0006 Optional Yes Community Authorization 0x0007 0x000C Optional Yes Path header 0x0008 0x000C Optional Yes Path Record header 0x0009 undef Undef Undef Connection header 0x000A 0x000C Optional Yes Multicast Session Announcement 0x000B 0x0006 Optional Yes Error 0x000C 0x0004 Optional Yes Multicast Session Report 0x000D >= Optional Yes Authentication 0x0004 0x000E 0x001C Optional Yes Encryption 0x000F 0x0008 Optional Yes Sequence header 0xFF00 N/A N/A (Experimental use) - 0xFFFF (1): Optional if the connection over which the message is being sent is detects transmission errors. (2): The 'Time to Live' and 'Hop count' fields are not included in the checksum of the PPMP header. If at any time there is a message processing error for which there is no known cause then the message MUST be discarded and an error message SHOULD be sent with the error code for 'Message error' and the error sub-code for 'Unspecified error'. A message with a header that has an invalid length MUST be discarded. An error message SHOULD be sent with the error code for 'Message error' and the error sub-code 'Invalid header length' Hessing Individual submission - Expires October 2002 8 draft-hessing-p2p-messaging-00.txt April 2002 4.1. PPMP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0001) | Header length (0x0024) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol v. | Forw. Mech. | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Flags |SegmentSecurity| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Servent ID (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Servent ID (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Servent ID (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Servent ID (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Hop count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Source/Destination Servent ID: Randomly-chosen 64 bit ID. For now the first eight bits MUST have the value 0x00. A servent MAY have multiple IDs. A community MAY define a requirement that a servent is only to use one ID for both joining the community and for sending and forwarding messages. A servent SHOULD use only one Servent ID for all its connections and messages unless there are privacy reasons in a supported community not to use a single Servent ID. A servent ID is not guaranteed to be unique as there is no coordination between servents in selecting servent IDs. - A message with a Source Servent ID of all zeros is an anonymous message. - A message with a Destination Servent ID of all ones is a broadcast message, to be received and processed by all servents. - Protocol version: as negotiated during the setup of the connection over which the message has been received or is to be send. - Forwarding mechanism: see the section 'Message forwarding'. - Message Length: 16 bit value. If the message length field contains the value 0x0000 then the message MUST include the Message Length header to indicate the length of the message. This method is used when messages are longer then 2 ^ 16 û 1 bytes. If the message length value in the PPMP header is 0x0000 and the message does not include the Message Length header then the message MUST be discarded Hessing Individual submission - Expires October 2002 9 draft-hessing-p2p-messaging-00.txt April 2002 and an error message SHOULD be sent with the error code for 'Message Error' and the Error sub-code 'Message length unknown'. See the section on the 'Message Length header' for more details. - Message ID: 16 bit value unique to the servent sourcing the message. - Flags: 8 bits Bit Value 0 Reliable transport between peers required. The connection MUST ensure that the message is received and is error-free. 1 Multicast transport allowed 2 Record route requested 3 Source Servent does not receive incoming connections 4-7 (Reserved) A servent sending a message MUST set the value of bits 4 to 7 to 0. If the flags are inconsistent with the community attributes then the message MUST be discarded. An error message SHOULD be sent with the error code for 'Message error' with the error sub-code for 'Invalid flags'. A message that has bit 0 of the flags set MUST NOT be send over a connection that does not validate whether the message was transported without errors. A servent which suspects it is behind a firewall and/or may not be able to accept incoming connections from other servents SHOULD set bit 3. - Segment Security: The Segment Security Code that is required for the transport of the message between two peers. - Time to live: 8 bits, number of hops that this message can be forwarded to before it should be discarded. The Source servent should set this value to the preferred time to live. Each servent that sends the message (including the Source servent) SHOULD reduce this time to live with one when sending the message. Messages received with a time to live of 0 MUST NOT be forwarded to other servents but SHOULD be processed locally. Hop count: 8 bits, number of times the message has been sent from one servent to another, when a servent receives a message it increases the hop count. The source servent thus sends the message with a hop count of 0. After the servent has received the message and incremented the hop count, the hop count plus the time to live SHOULD always match the original time to live as specified by the source servent. Hessing Individual submission - Expires October 2002 10 draft-hessing-p2p-messaging-00.txt April 2002 4.2. Checksum header The Checksum header allows errors to be detected by servents receiving a message. The checksum is calculated using the SHA1 algorithm as described in [3]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0002) | Header length (0x0008) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the checksum of a message does not match the locally calculated checksum then the message MUST be discarded. An error message SHOULD be sent with the error code for 'Message error' with the error sub- code for 'Checksum error'. Whenever a servent sends a message over a connection that does not validate the correct transmission of a message then the checksum header MUST be included even if that servent received the message without a checksum header. When a servent receives a message over a connection that does not validate the correct transmission of a message then the servent MUST verify the checksum. It MUST NOT remove the header when forwarding the header, even if this forwarding occurs over a connection that validates the correct transmission of a message. If a servent receives a message that does not have a checksum header over a connection that does not validate the correct transmission of a message then the message MUST be discarded. When a community defines capability specific headers it MUST specify whether these MUST be included in the checksum. Headers that have values that do not change per hop SHOULD be included in the checksum. Values that may change per hop MUST NOT be included in the checksum. The payload of a message is always used for computing the checksum unless the capability in the message that has provided the specification of the payload has defined that the payload should not be included in the checksum. The verification of a checksum is OPTIONAL if the message has been received over a connection that validates the error-free transport of the message. Hessing Individual submission - Expires October 2002 11 draft-hessing-p2p-messaging-00.txt April 2002 4.3. Message Length header The Message Length header is used to indicate the length of the message when this message exceeds 2 ^ 16 - 1 bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0003) | Header length (0x0008) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Length value is a 64 bit value. If the message length is less then 0x30 (the length of the PPMP header plus the message length header) then the message MUST be discarded and an error message SHOULD be sent with the error code for 'Message error' and the error sub-code for 'Invalid header length'. 4.4. Cease header Whenever a critical error occurs in the connection between peers then this connection MUST be terminated by the peer that noticed the error. This peer SHOULD send a message with only the PPMP header, the CEASE header described in this section and a Checksum header if the connection over which the message is to be sent does not validate that the message is transported error-free. A message which contains a Cease header is called a Cease message. After sending the Cease message, the peer SHALL immediately close the connection to the peer causing the critical error and SHALL NOT process any messages forwarded by that peer which were still waiting to be processed. An error message MUST NOT be generated in response to a message that includes the Cease header. The Cease message MUST always use the Connection Management Community and MUST use the header values as specified for this community in the 'Connection setup and maintenance' section. Hessing Individual submission - Expires October 2002 12 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0004) | Header length (0x0006) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cease code | Cease Subcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following Cease Codes and Sub-codes are defined: Cease Cease Message code Message sub-code Code Sub- code 1 0 Unknown error 2 0 Connection denied Unspecified error 2 1 Connection denied Administratively prohibited 2 1 Connection denied Servent ID unacceptable 2 2 Connection denied Protocol Version not supported 2 3 Connection denied Time out value unacceptable 2 4 Connection denied Connection collision detected 3 0 Connection error Unknown error 3 1 Connection error Invalid Source Servent ID 3 2 Connection error Invalid Destination Servent ID 3 3 Connection error Invalid Forwarding mechanism 3 4 Connection error Invalid Time-to-Live 3 5 Connection error Invalid Protocol Version 3 6 Connection error Invalid community 3 7 Connection error Time out timer expired 4 0 Connection info Unknown information 4 1 Connection info Better connection available 5 0 Message error Unspecified error 5 1 Message error Invalid capability 5 2 Message error Invalid checksum 4.5. Path header The Path header is used to specify the route which a message should take through a P2P network Hessing Individual submission - Expires October 2002 13 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0007) | Header length (0x0008) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Servent ID (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Servent ID (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path headers can OPTIONALLY be used with all forwarding mechanisms. See the section on 'Fully Defined Path' on how to process this header when using this forwarding mechanism. The chapter on Forwarding Mechanisms defines how message forwarding should be performed for messages with one or more Path headers for the other forwarding mechanisms. The Path headers in the message are in the order of the servents the message should be sent past. A servent MUST remove the first Path header of a message if the Servent ID in that Path header matches one of its own Servent IDs. Whenever a servent removes a Path header from a message that has a checksum header, it MUST always verify the original checksum before removing the Path header and discard the message of the checksum is not correct. If the checksum does match the servent MUST remove the Path header and recalculate the checksum. When a Path header is present in a message it SHOULD NOT be considered to determine whether a message is a duplicate of another message. The normal rules for increasing the hop count and decreasing the time to live apply. The message SHOULD be not be forwarded when the time to live is 0 even if there are additional Path headers present in the message. 4.6. Path Record header The Path Record header is used to record the route a message takes through a P2P network Hessing Individual submission - Expires October 2002 14 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0008) | Header length (0x0008) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Servent ID (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Servent ID (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path Record headers MAY be used with all Forwarding Mechanisms. A servent receiving a message with the Path Record flag set SHOULD append a Path Record header to the list of already present Path Record headers. If no Path Record headers are present then it should put in the header directly after the PPMP header. The servent MUST put in the Path Record header the Servent ID it used during the establishment of the connection over which it is forwarding the message. This implies that for each connection it may need to add a different Path Record header if it has used different Servent Ids for setting up these connections. If the message also has a checksum header then the checksum MUST always be verified. Before forwarding the message over a connection but after adding the Path Record header the servent MUST recalculate the checksum and add it to the message. Path Record headers are only sent by servents forwarding a message. The servent sourcing the message MUST NOT include a Path Record header. The last servent processing a message with one or more Path Record headers present SHOULD send a message back to the Source Servent ID belonging to the same community, without the Record Route flag set but with the Path Record headers that are present in the message. This last servent can either be the destination servent or one or more servents that receive the message with a Time-To-Live of zero. 4.7. Connection header The p2p protocol is in itself connectionless. Although TCP [4] is one of the transport mechanisms specified as a means for the transport messages between two peers, servents can exchange messages by using the forwarding services of other servents and these intermediate servents do not guarantee the delivery of the message. At this time the need for a connection mechanism on top of the message transport facilities is unclear. Whenever such a mechanism would be implemented, servents would need to take into account that when one or more Connection headers are present in a message that Hessing Individual submission - Expires October 2002 15 draft-hessing-p2p-messaging-00.txt April 2002 these headers should also be used to determine whether or not a message is a duplicate message. It is anticipated that a messages sent over an end-to-end connection between servents would be using two Connection headers, one for indicating which information is being sent in the message and one header to indicate which information has already been received by the other servent. 4.8. Authentication header The Authentication header MUST be included in a message when: . A message is sent that uses the Authentication for Path Security (see the section on Path security for more information) . A message contains a Community Description header for a community with a Community Join Requirement of AUTHENTICATED (see the sections on Community announcements and Joining a Community for more information) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x000D) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fingerprint (0 .. 19) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fingerprint is the 20 byte SHA1 hash of the public key packet- tag followed by the 2 byte value of the length of the public key followed by the entire public key packet. The string contains the result of the authentication algorithm over the public key SHA1 hash of the message contents. All message content that is used to compute the Checksum header is also used to calculate the SHA1 hash. 4.9. Encryption header A message using encryption for Path Security (see the section on Path security for more information) MUST include the Encryption header in the message. Hessing Individual submission - Expires October 2002 16 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x000E) | Header length (0x1C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fingerprint (0 .. 19) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the capability headers and the message payload MUST be encrypted. The protocol headers MUST NOT be encrypted. The fingerprint allows the destination servent to select the right public key to decrypt the message. The fingerprint is the 20 byte SHA1 hash of the public key packet- tag followed by the 2 byte value of the length of the public key followed by the entire public key packet. 4.10. Error header A servent SHOULD send an error message, that is, a message with an Error header, in response to a message that has generated an error. It should send this Error message only if the error has not caused the connection over which the message was received to be ceased. The servent uses the Source Servent ID of the message that has caused the error as the Destination Servent ID in the Error message. The Error message is send via the community to which the original message belonged. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x000B) | Header length (0x0006) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error code | Error Subcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Error message MUST NOT be send if the Source Servent ID of the original message used the anonymous Servent ID of 0x0000. An error message MUST consist of the PPMP header, the Error header and a Checksum header if the message is send over a transported mechanism which does not validate the correct transmission of the message. An error message SHOULD include in its payload the headers of the message that generated the error. No other headers SHOULD be included in the message. The total length of the Error message SHOULD NOT exceed 1000 bytes. The following Error Codes and Sub-codes are defined: Error Error Message code Message sub-code Code Sub- code Hessing Individual submission - Expires October 2002 17 draft-hessing-p2p-messaging-00.txt April 2002 1 0 Unknown error N/A 2 0 Message error Unspecified reason 2 1 Message error Checksum error 2 2 Message error Malformed PPMP header 2 3 Message error Undefined header type 2 4 Message error Invalid header length 2 5 Message error Message length unknown 2 6 Message error Invalid flags 2 7 Message error Invalid header type 2 8 Message error 'Source Servent does not receive incoming connections' flag should not be set 5. Message forwarding Each community MUST define a set of supported message forwarding mechanisms out of a list of forwarding mechanisms that are defined in this protocol and possible future extensions to this protocol. The source servent selects the forwarding mechanism for a message from the list supported by the community to which the message will belong. It encodes the forwarding mechanism to be used in the Forwarding Mechanism field in the PPMP header of the message. The rules for forwarding the message for that forwarding mechanism MUST then be followed by each servent forwarding the message. A servent that receives a message with a forwarding mechanism that is not listed in the set of forwarding mechanisms supported by the community MUST discard the message. A servent MAY NOT change the forwarding mechanism of a message it has received. The currently defined forwarding mechanism codes (FMC) are: FMC Name 0x00 (Reserved) 0x01 Direct connected only 0x02 Broadcast 0x03 Routed 0x04 Fully Defined Path 0x05 Multicast 0xF8-0xFF (Experimental use) Messages received with a time-to-live of zero MUST NOT be forwarded to other peers regardless of the forwarding mechanism. When a message has a time-to-live greater then zero then a servent MUST decrease the time-to-live in the message before it sends the message to one or more of its peers. A servent receiving a message with one of its own Servent IDs as Destination Servent ID and one or more Path headers MUST ignore the Hessing Individual submission - Expires October 2002 18 draft-hessing-p2p-messaging-00.txt April 2002 Path headers and process the message as it would have done if the Path headers are not present. Messages that do not use the 'Fully Defined Path' forwarding mechanism but do have one or more Path headers SHOULD be forwarded based on the value of the first Path header. A servent that receives one of these messages with the Servent ID in the first Path header matching one of its own Servent IDs MUST strip this Path header from the message before forwarding it. The servent SHOULD forward the message based on the Servent ID value of the next Path header or, if there are no more Path headers, the value of the Destination Servent ID. A message that uses the 'Direct connected only' forwarding mechanism MUST NOT be forwarded, even if it has a time to live greater than one or one or more Path headers exist in the message. Servents in communities that specify 'Direct connected only' as only forwarding mechanism will have to learn about other servents using services, capabilities of other communities or out-of-band means. 'Direct connected only' forwarding mechanism MUST be supported in all servent implementations as it is used during connection establishment. 5.1. Broadcasting Broadcasting is the traditional forwarding mechanism in p2p networks. A servent receiving a message from peer A for community X SHOULD forward that message to all of its peers that have announced community X to it except peer A if the message upon receipt has a time to live greater then 0. For more information on community announcements see the section 'Communities'. It is obvious that this forwarding mechanism leads to great scaling problems in any p2p network with a large number of servents. If we take into account however that servents are not required to forward messages to all its peers but should provide a best effort service to deliver the message to its destination then there are several optimalisations possible that reduce the amount of messages on a p2p network. A servent is SHOULD optimize its broadcasting algorithm. There are a number of ways to perform this optimalisation: - Maintaining a message cache to avoid duplicate messages and to match 'request' and 'response' messages. As discussed in the section 'Messages' it is possible that a servent receives a message belonging to the same Community, from the same Source Servent ID with the same Message-ID and without a Connection header multiple times. In that case it MUST silently discard all duplicates. This avoids duplication of messages on the network. The second Hessing Individual submission - Expires October 2002 19 draft-hessing-p2p-messaging-00.txt April 2002 application of a message cache is to match request and response messages as will be discussed in the section 'Capabilities'. A servent receiving a response message for which it earlier received the corresponding request message from the same Community, with the same Message ID and where the Source Servent ID of the request message equals the Destination Servent ID of the response message SHOULD forward the message only to the peer from which it received the request message the first time, if there is no Path header present in the response message. If the servent has never seen the corresponding request message then it SHOULD forward the message using the normal broadcasting algorithm. - Maintaining a servent cache by monitoring messages that it receives from other peers, whether these messages are destined for it or not. Each time a servent receives a message it should examine the Source Servent ID and the hop-count. If a message sourced by servent A has a lower hop-count then any other message sourced by servent A then it should note the peer B from which it has received the message as having the shortest path to servent A. It should then forward messages destined for servent A only to peer B. Care should be taken that messages that have one or more Path headers should not be used to build up the servent cache as their specified routing may be different then the optimal routing of messages on the p2p network. Other message forwarding optimalisations MAY include hierarchical servent relationships or proxying response messages. Hierarchical servent relations introduce a client-server relationship into the p2p model. This can reduce the burden of message forwarding on the servents acting as a client. Message proxying allows a servent to provide a response for another servent. This other servent will then see less messages and this would reduce load on that servent. Message proxying depends on the capability that is used in the message. Message proxying techniques are thus defined in the definition of the capability. 5.2. Routed It may be possible to develop a routing protocol for p2p networks although making it scalable will be a complex task. It may be possible to flood peer information of only a limited number of hops between peers. Assuming that p2p networks will automatically select communication between peers that are in close network proximity then this limited depth flooding may provide sufficient information to provide significant performance benefits but this is for further study. A routing table would need to be maintained for each community as different community memberships may cause the routing of messages Hessing Individual submission - Expires October 2002 20 draft-hessing-p2p-messaging-00.txt April 2002 belonging to different communities between two peers may take different path. 5.3. Fully Specified Path The Fully Specified Path forwarding Mechanism uses Path headers to specify every hop in the path between the source and the destination servents. A servent receiving a message using the Fully Specified Path forwarding mechanism MUST first verify that there are one or more Path headers in the message. If there are no Path headers then the message MUST be discarded. Otherwise if there are one or more Path headers in the message then the servent MUST compare the servent ID of the first Path header of the message with its own Servent IDs. If the servent ID in the Path header does not match one of its own Servent IDs then it MUST discard the message. Otherwise it MUST strip the first Path header from the message and base its message forwarding on the next Path header. If there are no more Path headers and the Destination Servent ID matches one of the Servent Ids of the servent then the servent SHOULD process the message locally. If there are more Path headers then it SHOULD forward the message based on the next Path header. It MUST only forward the message to a peer if the Servent ID in the Path header matches the Servent ID announced by the peer during the establishment of the connection to the peer. 5.4. Multicasting Messages using the multicast forwarding mechanism MUST be sent using technologies that allow one to many communication. One such technology is IP multicast but other technologies are being researched as well. There is a difference between multicast forwarding and multicast transport connections. Multicast forwarding can use IP multicast to transport messages but other techniques could also be introduced. Multicast transport can be performed for any message that is eligible for forwarding and that has the Multicast transport allowed flag set in the PPMP header. See the section 'Uni-directional IP multicast connections' on how messages can be transported using a multicast transport connection. Hessing Individual submission - Expires October 2002 21 draft-hessing-p2p-messaging-00.txt April 2002 6. Security profiles Every community has a security profile. This profile defines the requirements for servents to join a community and the requirements for the transport of messages and bulk data. 6.1. Requirements for joining a community A servent can join a community by making a connection to one of more other servents that are already member of the community and by negotiating with these peers the use of the community. The initial list of servents to connect to can be obtained by a service, a cached list of servents or by manual configuration. Once a servent has established a connection to a peer that is a member of a community and has successfully negotiated the use of the community through exchanging Community Description and Community Authorization and/or Authentication headers with the peer then he has virtually complete access to the community. The community a servent is a member of defines how that servent MUST validate an incoming request to join the community by another servent. See the section on Communities on how communities are negotiated between two peers using Community Description, Community Authorization and/or Authentication headers. If the Community Join Requirement is OPEN (CJR code 0x01) then it SHOULD always accept incoming connections unless there are reasons for the servent to deny the request, such as an internal blacklist or resource constraints on the local system. If the Community Join Requirement is AUTHORIZED (CJR code 0x02) then the servent requesting to join the community MUST present in the message with Community Description header a certificate in a Community Authorization header that is signed by a Certificate Authority known by both peers. If the community join requirement is AUTHENTICATED (community join requirement code 0x03) then the requesting peer MUST include an Authentication header with a signature created using its own secret key in the message with the Community Description header. The receiving peer MUST use the public key it has for the requesting peer to verify the signature. The Authentication header does not include its own Community ID field. For this reason only one community with the AUTHENTICATED community join requirement can be announced per message. Only one validation requirement can be supported within a community. The following Community Join Requirement (CJR) codes are defined: Hessing Individual submission - Expires October 2002 22 draft-hessing-p2p-messaging-00.txt April 2002 CJR code Description 0x00 (Reserved) 0x01 OPEN 0x02 AUTHORIZED 0x03 AUTHENTICATED 0xF8-0xFF (Experimental use) Communities that are announced with a reserved or undefined CJR MUST be ignored. 6.2. Security for the transport of messages The community can define what set of levels of security is required for the transport of messages between two servents. There are two security scopes defined: - Segment security: The security of sending a message between two peers. The sending peer can either be sourcing the message or forwarding a message it has received from another peer. - Path security: The security of sending the message from the source servent to the destination servent. 6.2.1. Segment security Messages can be transported over a connection between two peers only if a connection is available between the two peers with a security level that is supported by the community. It is thus possible that there are multiple connections between two peers to satisfy the security requirements of multiple communities. This is called connection duplication between two peers. The connection between two peers is called a segment in the context of the end-to-end path between a source servent and a destination servent. Establishing segment security is not part of this p2p protocol framework. Segment security MUST be provided by the connection mechanism used to establish a direct connection between two peers such as TLS [5] or another mechanism able to provide such security. When a servent is sending (sourcing or forwarding) a message and it has multiple connections to a peer, all supported by the community then it SHOULD use the connection with the least security in order to optimize performance of the community. The following Segment Security Codes (SSC) are currently defined for the connection between two peers: CLEAR (SSC 0x01): the messages are sent between peers in clear text Hessing Individual submission - Expires October 2002 23 draft-hessing-p2p-messaging-00.txt April 2002 AUTHENTICATED (SSC 0x02): the connection between two peers MUST provide authentication of all data that is being send over this connection. ENCRYPTED (SSC 0x03): the connection between two peers MUST encrypt all data that is being sent over this connection. The overview of Segment Security Codes (SSC): SSC Description 0x00 (Reserved) 0x01 CLEAR 0x02 AUTHENTICATED 0x03 ENCRYPTED 0xF8-0xFF (Experimental use) Communities that are announced with a reserved or undefined SSC MUST be ignored. 6.2.2. Path security Path security defines the security parameters for the transport of a message between the source and the destination servent. The following Path Security Codes (PSC) are defined: CLEAR (PSC 0x01): the messages are send in clear text AUTHENTICATED (PSC 0x02): the message MUST include an Authentication header. ENCRYPTED (PSC 0x03): the message MUST be encrypted and MUST include an Encryption header. It is possible that there are multiple servents for which the message is destined when multi- or broadcasting is used for the transport of the message. Path security must always use the option CLEAR when a message is destined to multiple servents. The options AUTHENTICATED or ENCRYPTED can only selected when unicast forwarding is used. This is expected to change in future revisions of this specification. The overview of Path Security Codes: PSC Description 0x00 (Reserved) 0x01 CLEAR 0x02 AUTHENTICATED 0x03 ENCRYPTED 0xF8-0xFF (Experimental use) Hessing Individual submission - Expires October 2002 24 draft-hessing-p2p-messaging-00.txt April 2002 Messages that are received with a Path Security Code that is either reserved or undefined SHOULD be discarded by the servent that receives such a message. 6.3. Data security The transport of bulk data within messages (in-band bulk data transfer) can use the security provisions that are available to the transport of messages. The transport of bulk data between two servents directly where the connection is made specifically for this data transport and where the use of the PPMP protocol is not required (out-of-band data transfer) can use the transport protocol defined in the section 'Out of band data transport' or any other transport protocol that a community wishes to define. This transport protocol will then provide the security for the data transport. 7. Connection setup and maintenance Connections between servents are used to transport messages from one servent to another. Servents that have a direct connection to each other are called peers. Connections can be made between two or more peers. The servent initiating the connection is called the requesting peer. The servents to which the connection is made are called the receiving peers. A single connection can be used for passing messages belonging to different communities. This is called connection sharing. A connection does thus not belong to a community. A connection is an available resource that can be used by a community if it meets the security requirements of the community. Different technologies are supported through which the connection can be established. A small number of connection mechanisms are described in this document but future revisions of this document or other standards can specify additional technologies. The mechanism is not required to be reliable, nor are there real-time requirements. It is thus possible that a message send by a peer over a connection is not received by the other peer nor is it guaranteed that the message will be received within a specific time frame. A connection mechanism will also not need to guarantee that messages are transmitted in the order they were sent. A transport mechanism MUST define the maximum size of a message which can be transported over the connection without the use of the Connection header. It MUST also specify whether the connection will be reliable and whether the connection validates that messages have been transported without errors. Hessing Individual submission - Expires October 2002 25 draft-hessing-p2p-messaging-00.txt April 2002 Communities requiring reliable message transport MUST specify this in their definition. Communities MAY NOT specify which technology is used for the transport of messages. They MUST specify the security requirements, whether messages MUST use reliable transport between peers and whether multicast forwarding is permitted. Messages belonging to a community that has not required the use of reliable connections can still be transported over reliable connections. Connection Transport Codes (CTC) are 8 bit values and are amongst others used in Ping messages (see the section on the Ping capability). The following Connection Transport Codes are defined: CTC Description 0x00 (Reserved) 0x01 TCP 0x02 TLS 0x03 UDP [6] 0x04 UDP/Multicast 0xF8-0xFF (Experimental use) CTC 0x01 uses TCP to provide reliable, error-free transport of messages of unlimited length. It provides bi-directional communication between two peers and connections and communities MUST be negotiated. CTC 0x02 uses TLS to provide reliable, error-free transport of messages of unlimited length. It provides bi-directional communication between two peers and connections and communities MUST be negotiated. Connections over TLS work conceptually the same as over TCP. The requesting peer connects to the receiving peer on the appropriate port, acts like a TLS client and sends a TLS ClientHello to begin the TLS handshake. When the TLS handshake is finished it starts negotiating the connection. All messages MUST be sent as TLS 'application data'. Connections made using TLS MUST initiate an exchange of closure alerts before closing a connection. CTC 0x03 uses UDP to provide unreliable, error-free transport of messages of up to 1400 bytes. A servent MUST ensure that UDP checksums are enabled on the host it is running. CTC 0x03 provides bi-directional communication between two peers and connections and communities MUST be negotiated. CTC 0x04 uses UDP to provide unreliable, error-free transport of messages of up to 1400 bytes. A servent MUST ensure that UDP checksums are enabled on the host it is running. CTC 0x04 provides uni-directional community from a servent to a set of peers. Connections and communities MAY NOT be negotiated. Hessing Individual submission - Expires October 2002 26 draft-hessing-p2p-messaging-00.txt April 2002 A special community is defined for messages used for connection setup and maintenance: the Connection Management Community (Community ID 0x0000). Messages send to this Community MUST have an initial Time to Live of 1 and the forwarding mechanism MUST be Direct Connected Only (see the section on forwarding mechanism negotiation for the single exception to this rule). The Source Servent ID MUST be the Servent ID that was used during the connection setup and the Destination Servent ID MUST be the Servent ID that the peer announced during the connection setup. 7.1. Bidirectional Connections The establishment of bi-directional connections consists of: . Establishing the transport connection . Negotiation the connection parameters . Negotiation of supported forwarding mechanisms . Breaking the connection if a connection collision has occurred When peers attempt to establish a bi-directional connection they exchange a sequence of connection establishment messages. The connection will be in 'handshake' state during this sequence. If one of the messages during the handshake is not received within a specified time interval or a message is received out of sequence then the connection establishment has failed and the peer determining the failure MUST send a CEASE message to the other peer, MUST cease the connection and SHOULD release any resources reserved to establish the connection. Two peers MUST agree on the following parameters before starting to transmit messages over the connection: . Connection mechanism . Servent ID of both the requesting and the receiving peer . P2P protocol version . Time out value . Forwarding mechanisms supported When the two peers have agreed on these parameters then the connection becomes operational. The peers will then start also exchanging messages belonging to communities other then the Connection Management Community. 7.1.1. Establishing a bi-directional transport connection This document defines UDP, TCP and TLS as bi-directional connection mechanisms. They provide error-free transport of messages between two peers. By accepting an incoming UDP, TCP or TLS connection the receiving peer agrees to use it as connection mechanism. When a requesting peer supports multiple connection mechanisms, it can cycle through the different mechanisms in the order it prefers until a connection has been successfully negotiated. It can also establish Hessing Individual submission - Expires October 2002 27 draft-hessing-p2p-messaging-00.txt April 2002 multiple connections using different connection mechanisms to optimize message delivery. Even though UDP is a connection-less protocol, in a P2P network it is used for negotiating a bi-directional connection between two servents. The receiving peer MAY send a CEASE message after accepting the incoming connection with the cease code for 'Connection Denied', with the sub-code for 'Administratively prohibited'. While the connection is in 'handshaking' state, all messages MUST only consist of the following headers: . Basic header. . Checksum header if the connection mechanism is not error-free. . CEASE header if an error occurred These messages MUST use the Connection Management Community. 7.1.2. Negotiate bi-directional connection parameters After establishing the communication path and thus agree on the transport mechanism, the peers first MUST have to agree on the Servent IDs. The requesting peer MUST send a message with the parameters: . Source Servent ID: the servent IDs it wishes to use to communicate with the receiving peer for Connection Management messages. . Destination Servent ID: because the requesting peer does not know the Servent ID of the receiving peer, the requesting peer MUST use a Destination Servent ID of all ones. . Protocol Version: protocol version that the requesting servent prefers to use. The only protocol version defined in this document is version 1. . Message-ID: This MUST be set to the proposed connection time- out value in seconds. A time out value of zero means that no time out timer will be maintained. Only during connection establishment time is this field to be allowed to be used for this purpose. The receiving peer MAY send one the following CEASE messages: . A CEASE message with the cease code for 'Message errorÆ with the cease sub-code for 'Invalid checksum' if the checksum does not match the contents of the message. . a CEASE message with the cease code for 'Connection Denied' with the sub-code for 'Servent ID unacceptable' . a CEASE message with the cease code for 'Connection Denied' with the sub-code for 'Protocol version not supported' if the protocol version is not acceptable and it does not support or Hessing Individual submission - Expires October 2002 28 draft-hessing-p2p-messaging-00.txt April 2002 does not wish to announce the support of another protocol version. . a CEASE message with the cease code for 'Connection Denied' with the sub-code for 'Time out value unacceptable' If no error occurred the receiving peer SHOULD send a message consisting of the parameters: . Source Servent ID: the Server ID it wishes to use to communicate with the requesting peer for connection management messages. . the Destination Servent ID it has just received as Source Servent ID from the requesting peer. . Protocol Version: either the protocol version proposed by the requesting peer or the protocol version that it prefers itself. . Message-ID: either the time out value proposed by the requesting peer or the time out value that it is proposing itself. A time out value of zero means that no time out timer will be maintained. On receiving the message, the requesting peer MUST validate: . The checksum and send a CEASE message with the cease code for 'Message error' and the sub-code for 'Invalid checksum' if the checksum does not match the contents of the message. . The Destination Servent ID, if it does not matches its own announced Servent ID it MUST send a CEASE message with the cease code for 'Connection Denied' and the sub-code for 'Servent ID unacceptable' . The Protocol Version, it does not match its own announced Protocol Version then it MUST evaluate whether the Protocol Version announced by the receiving peer is acceptable. If not then it MUST send a CEASE message with the cease code for 'Connection Denied' with the sub-code for 'Protocol version not supported'. If the proposed Protocol Version is acceptable then this protocol version MUST be used for all further communication over this connection. . The time-out value specified in the Message-ID. If it does not match its own announced time-out value then it MUST either accept the received time-out value or send a CEASE message with the cease code 'Connection Denied' with the sub-code for 'Time out value unacceptable'. 7.1.3. Negotiate supported forwarding mechanisms for bi- directional connections If the two peers agree on the values for the Source and Destination Servent IDs, Protocol Version and Time out value then they start announcing which forwarding mechanisms they support. For each forwarding mechanism a peer supports it will send a message belonging to the Connection Management Community. The PPMP header MUST be used to indicate which forwarding mechanism is supported. Hessing Individual submission - Expires October 2002 29 draft-hessing-p2p-messaging-00.txt April 2002 This behavior is only allowed during the connection handshake, all other messages belonging to the Connection Management Community MUST use the Direct Connected Only forwarding mechanism as described in the beginning of this chapter. Each peer MUST compute the subset of its own supported forwarding mechanisms and the supported forwarding mechanisms as announced by the other peer. This is the set of forwarding mechanisms supported by this connection. Only messages using one of these forwarding messages are eligible to be sent over this connection. The Direct Connected Only forwarding mechanism must be announced as the last forwarding mechanism. Servents MUST always announce this forwarding mechanism because it is required to be implemented. This message will indicate the end of the negotiation of forwarding mechanisms. 7.1.4. Breaking bi-directional connection collision At this time connection collision can be detected. There are three possibilities: . There is no connection collision. . There are two or more connections between two identical servents with the same IP address pair, and the same Servent IDs but either the connection transport or the Protocol Version does not match. In this case there is no connection collision but care SHOULD be taken that messages are only sent over one of the two connections. . There are two connections between two identical servents, both with the same IP address pair, the same Servent IDs, the same connection transport, the same Protocol Version and where the set of supported forwarding mechanisms of one connection is equal to or a subset of the set of supported forwarding mechanisms of the other connection. In this case a connection collision has occurred. When this occurs the requesting peer MUST select the connection with the smallest set of supported forwarding mechanisms and send a CEASE message with the cease code 'Connection Denied' with the cease sub-code for 'Connection collision detected' and CEASE the connection. If the two sets of supported forwarding mechanisms are equal then the servent MUST cease the connection that has been established the shortest time. If there is no connection collision then the connection becomes operational and is available for general use. When a new bi-directional connection is established that has the same IP address pair, the same Servent IDs, the same connection transport, the same Protocol Version and where the set of supported forwarding mechanisms is a superset of an existing connection then Hessing Individual submission - Expires October 2002 30 draft-hessing-p2p-messaging-00.txt April 2002 this existing connection SHOULD be ceased with the cease code for 'Connection info' with the cease sub-code for 'Better connection available'. 7.1.5. Keepalive messages for bi-directional connections If peers have negotiated a time-out value larger then 0 for a bi- directional connection then they MUST maintain a timer that SHOULD be reset every time a message is received over the connection. A peer SHOULD cease the connection if no messages have been received over the connection from the other peers during the duration of the time-out value. The CEASE message MUST use the cease code for 'Connection error' with the sub-code for 'Time out timer expired'. When a message is received over a connection, it is not relevant whether it is a duplicate or whether its checksum is valid for resetting the timer. A servent MUST also maintain a timer per bi-directional connection to ensure that it sends at least one message over the connection during the time-out interval. If no regular messages are available for sending over the connection then a peer SHOULD generate a Keepalive message. A Keepalive message MUST belong to the Connection Management community and MUST only include the PPMP header and the Checksum header if the connection over which the message is send is does not validate the error-free transport of a message. Keepalive messages are also used to monitor the performance of the connection. They are used to measure the amount of packet loss and delay between two peers. A servent MAY send a Keepalive to the other peer for performance management. This message MUST belong to the Connection Management community and use a unique Message-ID. The peer recognizes that the message was not initiated by itself through the Message-ID and MUST respond immediately with a Keepalive message with the same Message-ID. The servent that originated the Keepalive recognizes the Message-ID of the Keepalive message as one that it has generated itself and calculates the delay between sending the original Keepalive and receiving the response. The servent MAY use the message delay and message loss values to trim its set of peers to the best performing and cease the connections to the worst performing peers. A servent MUST of course take into account that connections using a reliable transport mechanism will not experience message loss. Keepalive messages with a Message-ID of 0x00 are not intended for performance management. Servents SHOULD NOT respond to these Keepalives with a Keepalive message with the same Message ID. Hessing Individual submission - Expires October 2002 31 draft-hessing-p2p-messaging-00.txt April 2002 7.2. Multicast, unidirectional connections The establishment of a multicast uni-directional connection by a servent consists of the following steps: . Determining whether the servent should start forwarding messages using multicast for a community . Announcing that the servent is forwarding messages to a multicast group . Receiving feedback that there are listeners on the multicast group A servent MAY forward messages for a community using multicast if: . It is a member of the community. . The community has not specified that reliable transport is required . The community has specified that multicast forwarding is permitted. . The community join requirement code is OPEN (0x0001). . The community does not have asymmetric key encryption as only option for segment or path security. . It is not already receiving messages for that community using multicast even though it has attempted to do so. . It has sufficient bandwidth available to forward messages. . If does not have reasons to believe that its messages send via multicast are not received by a significant group of servents. The last requirement is kept vague intentionally. As IP multicast groups may become a scarce resource the number of IP multicast groups should remain limited. A servent should thus be confident that its use of IP multicast adds significant value to the community. 7.2.1. Multicast Session Announcement header The servent using multicast to forward messages for a community MUST periodically announce this forwarding channel to the community using the Multicast Session Announcement header in a message sent to the community for which it is using multicast: Hessing Individual submission - Expires October 2002 32 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x000A) | Header length (0x000C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTC | Port | Interval (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval(1) | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast IP address: class D address. CTC: Connection Transport used for this session. Port: port used for the connection transport. Bandwidth: Maximum bandwidth in Kbit/s that the servent will forward messages using this multicast transport session. Interval: a servent receiving messages using multicast from this servent SHOULD send a Multicast Session report once during every interval. A servent does not negotiate a community over a multicast uni- directional connection as it would over a bi-directional connection. The originating servent can assume that servents listening to the multicast connection already are a member of the community because the originating servent MUST only announce the multicast session using a message belonging to the community it will multicast. The servents listening to the multicast session thus know about the specification of the community and can validate the messages against this specification. Servents MUST consider the expected bandwidth requirements before joining a multicast session. 7.2.2. Multicast Session Report header Servents receiving messages belonging to a community using a multicast connection SHOULD send a report back to the servent transmitting the community once during every interval specified in the Interval field in the Multicast Session Announcement header. These servents MUST use the Multicast Session Report header in a message belonging to the community and MUST send that message to the originator of the multicast session. The originator of the multicast session can be determined by the received Multicast Session Announcement messages. Hessing Individual submission - Expires October 2002 33 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x000C) | Header length (0x0004) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Servents receiving a Multicast Session Report destined for another servent SHOULD check whether they already have sent or forwarded a Multicast Session Report message to this destination servent for the same multicast session during the last reporting interval. If that is the case then the servent SHOULD drop or delay the message to ensure that it only sends or forwards one Multicast Session Report per interval towards the servent originating the multicast connection. If a servent receives a Multicast Session Report for a multicast session it has not previously received a Multicast Session Announcement then it SHOULD forward the message to the destination servent without using the inverse proxying algorithm described above. 7.2.3. Sequence header Every message that is send using multicast transport MUST include the Sequence header. The Sequence header is included in the Checksum header and the servent sending a message over a multicast transport MUST calculate the checksum if a checksum header is included in the message and/or the message is using a transport mechanism that does not support error detection. The Sequence header length is 8 bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x000F) | Header length (0x0008) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Every time a servent forwards a message using multicast transport for a certain community it MUST increment the sequence number for that community by one. This increment allows receiving servents to notice when message loss occurs. A servent noticing significant loss of messages MUST leave the multicast session. 7.2.4. Forwarding messages over multicast transport Messages using the forwarding mechanism 'MulticastingÆ can be send over multicast connections. Messages using other forwarding mechanisms that have the 'Multicast transport allowedÆ flag set in the PPMP header SHOULD be forwarded according to the rules of the forwarding mechanism and MAY be forwarded using a multicast connection. If a servent forwards such a message using a multicast connection then it MUST NOT change the forwarding mechanism value in the PPMP header. Hessing Individual submission - Expires October 2002 34 draft-hessing-p2p-messaging-00.txt April 2002 A servent receiving a message using multicast transport MUST NOT further forward that message even if that message would otherwise be eligible for forwarding. 8. Communities In the context of p2p networks, communities are defined by: . Their membership requirements, i.e. open, authorized by well- known entity, authenticated by direct peers . Security requirements for the transport of messages and data . Capabilities: supported message headers . Services: key servers, network management servers . Message forwarding mechanisms: directly connected only, broadcast, routed, multicast, specified path . Connection types: uni- or bi-directional, reliable, error-free, real-time, multicast Peers MAY exchange messages belonging to a community only if the peers sharing the connection agree on the attributes of the community. The Community ID values are grouped as follows: Community ID Community Remarks 0x00000000 Connection Management Community 0x00000001 Network Management Community 0x00000002 - (reserved) Well-known communities 0x01FFFFFF MUST be registered with IANA before use 0x02000000 - Dynamically assigned, 0x09FFFFFF globally unique 0x0A000000 - Dynamically assigned, 0x0A999999 locally scoped 0x0B000000 - (reserved) Applications to be defined 0xFFFEFFFF 0xFFFF0000 - (Experimental use) 0xFFFFFFFF Well-known communities MUST be registered with IANA before they can be used. Dynamically assigned, globally unique communities MAY be initiated by a servent that wishes to start a (semi-) permanent community available to all servents using this protocol. Dynamically assigned, locally scoped communities MAY be created by servents wishing to initiate a community with a limited time of existence and a limited number of communities. Hessing Individual submission - Expires October 2002 35 draft-hessing-p2p-messaging-00.txt April 2002 8.1. Community Announcements After a connection that supports community negotiation has become operational, peers MAY exchange messages to announce that they are willing to accept messages for a community, as long the peers agree on the attributes of the community and the community join requirements are met. These messages use the Community Description and the Community Authorization headers, as discussed in the next two sections. A servent MAY create a community with a specific Community ID if that Community ID is in the range of dynamically assigned Community IDs and the servent has no knowledge of communities using the same Community ID. When the servent creates the community, it also defines the community attributes. It SHOULD then send a message with a Community Description header and possibly a Community Authorization header or an Authentication header for the newly created community over each of its operational connections. The servent may then receive announcements for the community back from one or more of its peers if a peer has accepted the community. The servent MAY then start sending messages to each peer that has accepted the community. Each servent MUST support the Community Description capability. The support for the Community Authorization- and the Authentication capabilities is optional. A servent that does not support either of these capabilities but receives a message with such a capability MUST ignore the capability and the Community Description header to which the unsupported capability references. When a servent finds that the attributes of a community it receives through a Community Description message do not match the attributes it has stored itself for that community then this is called a 'split community'. The servent MUST reject the Community Announcement message for such a community from its peer. The peers MUST NOT exchange messages belonging to the community over that connection. This should never happen with well-known communities. It can happen with dynamically assigned Community IDs and it can be expected to happen with dynamically assigned locally scoped Community IDs. Upon receipt of a Community Announcement message for a community of which it had no prior information a servent MAY accept this announcement. If the servent accepts the community then it MUST send a message with a Community Description header matching the original announcement to the peer from which it received the announcement. The servent MAY also send Community Announcement messages for the community over some or all of its operational connections to propagate the information about the community to its other peers. Hessing Individual submission - Expires October 2002 36 draft-hessing-p2p-messaging-00.txt April 2002 Starting communities which have a Community Join Requirement other then OPEN will require some external means of establishing authentication. For communities that use the AUTHORIZED join requirement the HTTP URL in the Community Description header could point to a web site where users can establish an identity and have the certificate authority used by that community validate that identify. The Connection Management community MUST never be announced over a connection. A servent MAY indicate that it no longer wants to receive messages belonging to a community by sending a Community Description header to its peers withdrawing that community. A servent receiving a message over a connection from a peer with a Community Description header withdrawing a community MUST stop sending messages belonging to that community to that peer over that connection. Communities with a Community ID out of the dynamically assigned range SHOULD be removed by a servent when the community is not statically configured in the servent, it has not created the community itself and it does not have any operational connections over which it has received announcements for the community. This can occur when: . Its peers have not announced the community (back) to it . Its peers have sent it a message with a Community Description header withdrawing the community. . All the connections over which it has received an announcement for the community have been terminated A peer SHOULD keep a timer on when it has last received a message belonging to a community that uses a dynamically assigned Community ID. This timer SHOULD also be reset whenever it receives a Community Description message for that community. The peer SHOULD send a message with a Community Description header withdrawing the community over all its connections which it has previously announced the community if it has not received any messages for that community for twenty-four hours. A servent MAY send duplicate announcements for a community to a peer to avoid that the community will time-out on that peer. 8.2. Community Description header A Servent MAY send a message with one or more Community Description headers for one or more communities over an operational connection that supports community negotiation. By sending a Community Description header, the servent announces that it is willing to accept messages for the community specified in the header, as long as the attributes of the community matches with the information Hessing Individual submission - Expires October 2002 37 draft-hessing-p2p-messaging-00.txt April 2002 about the community of the peer that is receiving the Community Description header and the Community Join Requirements are met. A Community Description header can only be used together with the PPMP header, the Checksum header, the Authentication header, other Community Description headers and Community Authorization headers. The message containing the Community Description header(s) MUST belong to the Connection Management Community (0x00000000). A Community Description message for a community that has a Community Join Requirement of AUTHORIZED MUST include a Community Authorization header. A Community Description message for a community that has a Community Join Requirement of AUTHENTICATED MUST include an Authentication header. The Community Description header is a variable length header and has the following lay-out: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0005) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status| Flags | Join Req. | Attributes(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes (1 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There are currently three different community status values defined: (Reserved) (0x00), Active (0x01) and Withdrawn (0x02). The Values 0x06 and 0x07 are for experimental use. The bits in the Community Description flags field have the following meaning: Bit Value 0 0 = Messages can be send both over reliable and unreliable connections 1 = Reliable transport between peers is required for any message belonging to this community 1 0 = Real-time transport is allowed 1 = Real-time transport is required 2 0 = Multicast transport is not allowed 1 = Multicast transport is allowed 3 0 = Record route requests are not allowed 1 = Record route requests are allowed 4 0 = Payload is not included in the checksum 1 = Payload is included in the checksum 5 0 = A servent MUST use only one Servent ID for both Hessing Individual submission - Expires October 2002 38 draft-hessing-p2p-messaging-00.txt April 2002 joining the community and sending messages to it 1 = A servent MAY use different Servent IDs for joining and sending messages to the community. 6 0 = Messages with the anonymous (0x00) Source Servent ID are not allowed. 1 = Anonymous messages are allowed 7-11 (reserved) The Join Requirement field specifies the Join Requirement Code for the community. The attributes supported by the community are announced sequentially in the header. Attribute sequences thus have a variable length. Each sequence of attributes is terminated by a null value. This null value has the same bit length as the attribute which sequence it terminates. Attribute sequences are sent in a specific order so that the receiving servent can parse the header. Attribute Representation Supported Forwarding mechanisms 8 bits Supported Segment security codes 8 bits Supported Path security codes 8 bits Supported out-of-band data transport mechanisms 8 bits Capability 24 bits The Capability attribute is a tuple consisting of a 16 bit Capability value followed by an 8 bit Capability Support Requirement (CSR). A 16 bit Capability value of null terminates the list of capabilities that are supported by the community. The Capability Support Requirement values are defined to: . (Reserved) 0x00 . Processing Required (0x01): A servent that can't process and forward this capability MUST reject the Community . Forwarding Required (0x02): A servent that doesn't support the forwarding of messages with this capability according to the forwarding rules for this Capability MUST reject this community. . Optional (0x03): A servent does not need to support this capability, the capability is optional . 0xF8-0xFF: (Experimental use) A servent receiving a Community Description message that lists attributes that it considers undefined MUST reject the community. A servent receiving a Community Description message that doesn't list a forwarding mechanism it supports MUST reject the community. A servent receiving a Community Description message that doesn't list a segment security code it supports MUST reject the community. Hessing Individual submission - Expires October 2002 39 draft-hessing-p2p-messaging-00.txt April 2002 A servent receiving a Community Description message that doesn't list an out-of-band data transport mechanism it supports MAY accept the community. An optional URI describing the community can be appended to the header after the last community attribute is terminated with a null value. The length of the URI can be determined by taking the header length value and decrementing that by the number of bytes read up to the start of the URI. The use of the URI information is not formally defined but could be used to direct the servent to an out-of-band authentication service or other resource. A community may specify the exact use of the URI. 8.3. Community Authorization header If the community has a community join requirement of AUTHORIZED (0x02) then a Community Authorization header MUST accompany the Community Description header in the message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0006) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The string is a DER encoded X509 [7] certificate which includes the public key of the requesting peer signed by a Certificate Authority known by both peers. The digital signature is over the PPMP header excluding the hop-count and time-to-live fields and the Community Description header for the community. If the signed certificate is not valid then Community Description header and the Community Authorization header for the community MUST be discarded. 9. Out-of-band Data Transport Servents wishing to exchange resources that require a significant amount of bandwidth MAY chose to do so using Out-of-band Data Transport (ODT). This section lists a number of available ODT mechanisms with references to their protocol definitions. Each community MUST define which ODT mechanisms it supports. ODT code Protocol 0x00 (reserved) 0x01 HTTP [8] GET 0x02 HTTP PUT Hessing Individual submission - Expires October 2002 40 draft-hessing-p2p-messaging-00.txt April 2002 0x03 HTTP over TLS [9] GET 0x04 HTTP over TLS PUT 0x05 IP MULTICAST 0xF8-0xFF (Experimental use) Currently Reliable Multicast Transport (RMT) is being defined the RMT working group in the Transport Area of the IETF. This working group is in the process of defining the building blocks of RMT. These building blocks can be used to specify multicast transport suitable for p2p networks. This specification can either occur in this work in progress or in a separate document. 10. Capabilities A capability is some functionality that is supported by a community. A capability consists of a capability-specific header and optionally an interpretation of the message payload. Each capability MUST define: . Capability header, its header code, its header length (fixed or variable), is the header included in the checksum and authentication or encryption headers? . Does the capability have to be fully supported by a servent joining the community? . Does the header provide a specification for the message payload, and if so, is the payload included in the checksum and authentication or encryption headers? . Is this a Request message, and if so what are the Response capabilities? . Is this a Response message, and if so, to what Request capabilities Messages that are a response to another message MUST use the same Community and the same Message-ID as used in the corresponding Request message. The Response message MUST use as Destination Servent ID the Source Servent ID of the corresponding Request message. A Capability can be a combination of both a Response to another message and a Request to one or more Servents. A capability can be Response message but can also be send without a corresponding Request message. Headers defined by capabilities MUST come after any headers as defined in the previous chapters. Multiple capability headers can be grouped in one message as long as at most one capability header provides a specification for the message payload. Hessing Individual submission - Expires October 2002 41 draft-hessing-p2p-messaging-00.txt April 2002 10.1. Ping capability The Ping header MUST be included in the checksum and any authentication or encryption headers. The message length is fixed at 0x0004 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0100) | Header length (0x0004) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pings can either be sent to a specific Servent ID or to the broadcast address. A ping message MAY NOT use the anonymous servent ID as source servent ID. A Ping message is a request for a Pong message. 10.2. Pong capability The Pong header MUST be included in the checksum and any authentication or encryption headers. The message length is fixed at 0x0004 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0101) | Header length (0x0004) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Pong message is a response to a Ping message. The Pong message MAY be send anonymously but this is not advisable as it will then only provide limited information to the requesting Servent. 10.3. Servent Discovery capability The Servent Discovery header MUST be included in the checksum and any authentication or encryption headers. The message length is fixed at 0x0004 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0102) | Header length (0x0004) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Pong message is a request for a Hello message. 10.4. Hello capability The Hello header MUST be included in the checksum and any authentication or encryption headers. The message length is variable Hessing Individual submission - Expires October 2002 42 draft-hessing-p2p-messaging-00.txt April 2002 with a minimum length of 0x000C. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0103) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Uptime | Phy. If. speed| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTC (0) | Port (0) | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. | CTC (n) | Port (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The uptime value SHOULD contain a 24-bit number of seconds that have elapsed since the host started providing services using this p2p protocol specification. The physical interface speed value MUST use the class value of the following 'interface speed' table that matches closest the physical interface with the highest capacity over which it accepts incoming P2P connections. A physical interface speed value of '0' indicates that the servent sending the hello does not want to announce this information. Class 0 1 2 3 4 Speed N/A 56.1Kbit 256Kbit/s 512Kbit/s 1.5/2Mbit/s Class 5 6 7 8 9 Speed 10Mbit/s 45Mbit/s 100Mbit/s 155Mbit/s 620Mbit/s Class 10 11 12 13 14 Speed 1Gbit/s 2.4Gbit/s 10Gbit/s 40Gbit/s 160Gbit/s A servent SHOULD use the IP address of the interface over which it accepts incoming p2p connection supporting the highest bandwidth in the IP address field. A servent MAY use 0.0.0.0 as IP address to indicate it wants to keep its IP address private. Each CTC/Port pair specifies which connection transport mechanisms are supported on which ports. Hellos can either be sent to a specific Servent ID or to the broadcast address. By including information about its uptime and physical interface speed it allows the other servents in the p2p network that receive the message to learn about it. The Hello message is a response to a Servent Discovery message. 10.5. Connection Advise capability The Connection Advice header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x000C bytes. The header does not Hessing Individual submission - Expires October 2002 43 draft-hessing-p2p-messaging-00.txt April 2002 specify the message payload. It is neither a Request nor a Response header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0104) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Uptime | Phy. If. speed| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTC (0) | Port (0) | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTC (n) | Port (n) | Pref. Len (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP prefix (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. | Pref. Len (m) | IP prefix (m) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Connection Advise message MAY be send with an anonymous Source Servent ID. The servent sending out the request MUST use its own IP address in the IP address field. The uptime, phy. if. speed, CTC and Port fields use the same encoding as in the Hello header. The CTC/Port sequence is terminated by two bytes with a null value. The servent sending a Connection Advice message does so to optimize connectivity on a transport network level. It advices other servents that it is providing good p2p connectivity to servents with an IP address in one of the IP address prefixes included in the header. A Connection Advice header MUST NOT be included in a message with the 'Source Servent does not receive incoming connections' bit set in the PPMP header 10.6. Community Discovery capability The Community Discovery header MUST be included in the checksum and any authentication or encryption headers. The message length is fixed at eighth bytes. The header does not specify the message payload. It is a Request for a Community Invitation message. Hessing Individual submission - Expires October 2002 44 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x010F) | Header length (0x0008) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A servent can send the Community Discovery capability to a community like the Network Management community to find out servents that support a certain community. This can be used to establish connections to servents that carry a certain community that is not supported by the current peers of a servent. 10.7. Community Invitation capability The Community Invitation header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0010 bytes. The header does not specify the message payload. It is neither a Request nor a Response header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0105) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Uptime | Phy. If. speed| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTC (0) | Port (0) | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. | CTC (n) | Port (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encoding of the Uptime, Phy. If. speed, IP address, CTC and Port fields is the same as in the Hello capability. The Community Invite capability is used to invite another servent to join a community by making a connection to the servent using the IP address of the IP address field using one of the Connection Transport mechanisms listed in CTC/Port pairs. The Community Invite capability can be used stand-alone or as a Response to a Community Discovery message. Only servents that can receive incoming connections MAY send the Community Invite header. A Community Invite header MUST NOT be Hessing Individual submission - Expires October 2002 45 draft-hessing-p2p-messaging-00.txt April 2002 included in a message with the 'Source Servent does not receive incoming connections' bit set in the PPMP header. 10.8. XML Query capability The XML Query header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0004 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0106) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XML string (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The XML string is the XML compliant [10] ASCII string representing a query. A community supporting this capability MUST define which Docbooks may be used in these queries. The XML Query message is a Request message and the XML Response message is its response message. 10.9. XML Response capability The XML Response header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0004 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0107) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ODTC (0) | Port (0) | .. | ODTC (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port (n) | URI (0..m) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XML string (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ODTC/Port tuple fields are a list of Out-of-band Data Transport mechanisms that can be used to retrieve a resource. This list is terminated by two bytes with the null value. The URI field is a null-terminated ASCII string providing the location where the resource is available for retrieval. Hessing Individual submission - Expires October 2002 46 draft-hessing-p2p-messaging-00.txt April 2002 The XML string is the XML compliant ASCII string representing a response to an XML Query header. A community supporting this capability MUST define which Docbooks may be used in these responses. The XML Response header is a response to the XML Request header. 10.10. Resource Push Request capability The Resource Push Request header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x000C bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0108) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ODTC (0) | Port (0) | .. | ODTC (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port (n) | +-+-+-+-+-+-+-+-+ If servent A has received a XML Response message from servent B with the 'Source Servent does not receive incoming connectionsÆ flag set in the PPMP header then it MAY send a Resource Push Request message to servent B. Servent A lists in this message the Out-of-band Data Transport mechanisms it supports together with the ports it is using for these transport mechanisms. It also provides the IP address on which it can receive the out-of-band data transport. Servent B MAY then initiate the resource exchange by using the out- of-band transport mechanism to servent A. It will use as identifier for the resource the string consisting of the community ID and the Message ID of the Resource Push Request message. A servent that does not receive incoming connections MUST not send Resource Push Requests as the receiving servent will not be able to establish a connection to it. A servent receiving a Resource Push Request message with the 'Source Servent does not receive incoming connections' flag set in the PPMP header MUST discard this message and SHOULD send an error message with the error code for 'Message error' and the error sub-code for 'Source Servent does not receive incoming connections' flag should not be set'. Hessing Individual submission - Expires October 2002 47 draft-hessing-p2p-messaging-00.txt April 2002 10.11. Algorithm Request capability The Algorithm Request header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0005 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x0109) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Language | +-+-+-+-+-+-+-+-+ The Language field MUST use one of the following codes: Code Description 0x00 (Reserved) 0x01 Perl 0x02 Phyton 0x03 Java 0x04 C 0x05 C++ 0x06 C# 0x07 Win32 binary 0x08 Linux ELF Intel-32bit binary 0x09 Sun/Solaris binary 0xF8 - 0xFF (Experimental use) The Algorithm Request message is a Request message to which the Algorithm Response message is the Response. 10.12. Algorithm Response capability The Algorithm Response header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0005 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x010A) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Language | Algorithm ID | Code (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A header length of 0x0005 indicates that there is no source code available for the algorithm in the language selected in the Algorithm Request message. Hessing Individual submission - Expires October 2002 48 draft-hessing-p2p-messaging-00.txt April 2002 The Algorithm ID field is an identifier for the algorithm provided in this Algorithm Response message. The Code field is a null terminated string which includes the source code for the algorithm. Servents receiving an algorithm MUST ensure that executing the received code will bring no damage to the host the servent is running on. The Algorithm Response message is a Response to an Algorithm Request message. 10.13. Dataset Request capability The Dataset Request header MUST be included in the checksum and any authentication or encryption headers. The message length is fixed at 0x0006 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x010B) | Header length (0x0006) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Algorithm ID MUST have been received in a previous Algorithm Response message. The Dataset Request message is a Request message for which the Dataset Response message is the Response. 10.14. Dataset Response capability The Dataset Response header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0008 bytes. The header does not specify the message payload. Hessing Individual submission - Expires October 2002 49 draft-hessing-p2p-messaging-00.txt April 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x010C) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dataset ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A header length of 0x0008 indicates that there is no data available for processing using the algorithm specified in the Dataset Request message. The data field is a null-terminated ASCII string that can be fed to the algorithm for processing. The Dataset Response message is a Response to the Dataset Request message. It is also a Request for a Dataset Result message. 10.15. Dataset Result capability The Dataset Result header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x000A bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x010D) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm ID | Dataset ID (0,1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dataset ID (2,3) | Result (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Algorithm ID MUST have been received in a previous Algorithm Response message. The Dataset ID MUST have been received in a previous Dataset Response message. The Result field is a null-terminated ASCII string with the output from the algorithm with the dataset as input. The Dataset Result message is a Response to a Dataset Response message. Hessing Individual submission - Expires October 2002 50 draft-hessing-p2p-messaging-00.txt April 2002 10.16. Chat capability The Dataset Result header MUST be included in the checksum and any authentication or encryption headers. The message length is variable with a minimum length of 0x0006 bytes. The header does not specify the message payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header type (0x010E) | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender (0 .. m) | Text (0 .. n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sender field is a null-terminated ASCII string identifying the person sending the chat message. The text field is a null-terminated ASCII string with the chat message. 11. Network management The goal of network management of a p2p network is to keep the network operational and efficient as to maximize the performance and usability for the end users. Network management occurs at three levels: . Connection Management with the Connection Management community, using Keepalive and Community Description messages. . The Network Management community . Community-defined network management capabilities The Network Management community requires a servent to support the capabilities: Ping, Pong, Hello, Servent Discovery, Community Discovery, Community Invitation and Connection Advice. Servents MUST support the processing and forwarding of these capabilities when they are in a message with CLEAR Path Security. Servents MUST support the forwarding of these messages with the Path Security options AUTHENTICATED and ENCRYPTED. Messages belonging to this community MAY be sent both over reliable and un-reliable connections, MAY use multicast transport. Real-time transport of messages is not required. Record Route requests are allowed, a servent MAY use multiple Servent IDs when originating messages for this community. A servent MAY also use the anonymous Servent ID when originating messages for this community. The Payload is included in the checksum. The supported forwarding mechanisms are 'Direct Connected Only' and 'Broadcasting'. There is no out-of-band data transfer method supported. The Community Join Requirement is 'OPEN'. Messages MAY be transported over CLEAR, AUTHENTICATED and ENCRYPTED segments. Hessing Individual submission - Expires October 2002 51 draft-hessing-p2p-messaging-00.txt April 2002 The network can be optimized at two levels: matching the p2p network optimally with the underlying transport network and by providing optimal connectivity between servents. Connection Advice messages can be used to improve the matching between the p2p network and the underlying transport network. Network Discovery and Hello messages can be used to match servents with similar interface speeds and to find potential peers that are stable. Some p2p networks implement hierarchical mesh construction and indeed this would also be possible to do with p2p networks build using this protocol specification. However, the requirements of such a mesh is dependent on the goals of the community. It is thus left up to the community definition to specify how hierarchy within the community is established. 12. Security considerations P2P networking is open to a number of well known attacks and is introduces a number of new potential attacks. At the application level, the servent will introduce the delivery of services on some computers which traditionally would not provide service to other computers. The users of these computers may not have experience with running a computer that provides services to other computers and the inherent security risks included. At the protocol level, the security measurements available in this protocol should be used to prevent man-in-the-middle and eavesdropping attacks and ensure that only authorized users can connect to a community. At no time should a servent rely solely on the Source Servent ID field to establish the identity of another servent. It is trivially easy to spoof this ID. If broadcasting is used as forwarding mechanism then spoofing is also more effective then in traditional IP networks because the spoofing client is very likely to receive any response message for the spoofed Servent ID. The protocol ensures that existing communities are protected from peers trying to remove or to modify the specifications of these communities. A servent should however limit the amount of new communities a peer may introduce to prevent starvation of Community ID space and to limit impact when a peer introduces bogus community descriptions for existing communities of which the servent is not yet a member of. Denial of Service attacks are possible against individual servents and indeed the p2p network. Servents should implement rate-limiting to control the amount of messages it will accept from a peer. Similarly, it should implement queuing algorithms for outgoing Hessing Individual submission - Expires October 2002 52 draft-hessing-p2p-messaging-00.txt April 2002 messages that prioritize control messages over other messages to ensure that the network keeps running during a DoS attack. Communities need to carefully balance security requirements with p2p network performance. The hop-by-hop authentication or encryption of messages does increase computations on intermediate servents but it will allow the servents to analyze the message and learn about the p2p network from it. Running applications or code that is received through Application Response headers brings risk. The code may contain viruses or trojan horses. Application Response headers should use authenticated or encrypted transport or servents should use other means of protecting the host it is running on, for example those used to run client-side code using java in web-browsers. 13. IANA Considerations This section uses the terminology as defined in the RFC 2434 [11]. The 'Community ID' namespace uses 32 bit numbers. This address space is carved up as: . 0x00: Connection management community . 0x01: Network management community . 0x00000002 - 0x01FFFFFF: to be assigned by IANA after expert review or specification. . 0x02000000 - 0x0A999999: no assignment by IANA required, freely usable. . 0x0B000000 - 0xFFFEFFFF: reserved, assignment by IANA only to commence after IETF consensus on the use of this address space . 0xFFFF0000 - 0xFFFFFFFF: private use Both the PPMP and the Community Description header have their own flags field with several bits not given an interpretation. The interpretation of these bits is to be assigned by IANA after specification. The Status namespace is used in the Community Description header and contains 4-bit values. Values for the Status namespace can be assigned by IANA after specification. The Capability Support Requirement is used in the Community Support Description and containts 8-bit values. Values for this namespace can be assigned by IANA after specification. The Header Type namespace contains 16 bit values. The values 0x0000 up to and including 0x008F are to be used for protocol headers, the values 0x0100 up to 0xFFF0 are to be used for capability headers. The values 0xFFF0 up to and including 0xFFFF are to be used for Hessing Individual submission - Expires October 2002 53 draft-hessing-p2p-messaging-00.txt April 2002 private use. Values from the protocol header and capability header ranges can be assigned by IANA after expert review or specification. The following namespaces all contain 8 bit values. This document specifies a number of values in each of these namespaces, please see the appropriate section. Each of these namespaces has a range of values that is defined as experimental which translates to 'private use' in RFC 2434 terminology. Additional values can be assigned by IANA after expert review or specification. The namespaces are: . Segment Security . Path Security . Community Join Requirement . Connection Transport . Out-of-band data transport . Language Each registration of the namespaces listed in this section can be amended by the author and the IESG has the right to re-assign ownership of the registration. Hessing Individual submission - Expires October 2002 54 draft-hessing-p2p-messaging-00.txt April 2002 14. References 1 RFC 2026, Bradner, S., 'The Internet Standards Process -- Revision 3', BCP 9, October 1996 2 RFC 2119, Bradner, S., 'Key words for use in RFCs to Indicate Requirement Levels', BCP 14, RFC 2119, March 1997 3 FIPS PUB 180-1, 'Secure Hash Standard', National Institute of Standards and Technology, April 1995 4 RFC 793, Postel, J., 'Transmission Control Protocol', September 1981. 5 RFC 2246, T. Dierks, C. Allen. 'The TLS Protocol Version 1.0', January 1999 6 RFC 768, J. Postel, 'User Datagram Protocol'. Aug-28-1980 7 CCITT, Recommendation X.509, The Directory-Authentication Framework, Consultation Committee, International Telephone and Telegraph, International Telecommunications Union, Geneva, 1989. 8 RFC 2616, 'Hypertext Transfer Protocol û HTTP/1.1'. 9 RFC 2818, E. Rescorla, 'HTTP Over TLS', May 2000 10 Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation. eds. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen and Eve Maler. 6 October 2000. http://www.w3.org/TR/REC-xml 11 RFC 2434, Narten & Alvestrand, 'Guidelines for IANA Considerations', October 1998 Hessing Individual submission - Expires October 2002 55 15. Author's Address Steven Hessing steven@xs4all.nl Two mailing-lists have been set up for this specification: . ppmp-announce@lists.sourceforge.net for announcements about the PPMP protocol . ppmp-spec@lists.sourceforge.net for discussion about the specification of the protocol 16. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an 'AS IS' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.'