idnits 2.17.1 draft-strauss-p2p-chat-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1377. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Each MESSAGE message contains a UTC timestamp which is generated by the original sender. This timestamp MAY be used to put the received message into the context of a discussion. Note that there is typically no global time in a MANET. Therefore, this timestamp depends on the peer sending the message and timestamps from different peers MAY NOT be consistent. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2007) is 6220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 573 -- Looks like a reference, but probably isn't: '10' on line 573 == Unused Reference: 'RFC2234' is defined on line 1290, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUX667' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Strauss 3 Internet-Draft TU Braunschweig 4 Expires: October 3, 2007 S. Ransom 5 Universitaet zu Luebeck 6 S. Lahde 7 O. Wellnitz 8 TU Braunschweig 9 April 2007 11 P2P CHAT - A Peer-to-Peer Chat Protocol 12 draft-strauss-p2p-chat-08 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 3, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This memo presents the third version of a protocol for a peer-to-peer 46 based chat system. In this version it is extended for supporting 47 message exchange in Mobile Ad Hoc Networks (MANETs) that suffer from 48 node mobility. Messages can be cryptographically signed, encrypted 49 and anonymized allowing authentic and closed group communication as 50 well as anonymous communication. This work is input for a practical 51 course on software engineering at Technische Universitaet 52 Braunschweig. It is experimental work that is not intended to go to 53 the IETF standards track. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terms of Requirement Levels . . . . . . . . . . . . . . . 5 60 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. The Peer-to-Peer Network . . . . . . . . . . . . . . . . . 6 62 2.2. Infrastructure Mode . . . . . . . . . . . . . . . . . . . 6 63 2.3. Mobility Issues . . . . . . . . . . . . . . . . . . . . . 6 64 2.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.6. Anonymous Communication . . . . . . . . . . . . . . . . . 9 67 3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.1. Protocol Message Format . . . . . . . . . . . . . . . . . 10 69 3.2. Protocol Message Exchange . . . . . . . . . . . . . . . . 10 70 3.3. Protocol Messages . . . . . . . . . . . . . . . . . . . . 10 71 3.3.1. HELLO . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.2. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.3.3. NACK . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.3.4. CHANNEL . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.3.5. JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.3.6. LEAVE . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.3.7. GETCERTIFICATE . . . . . . . . . . . . . . . . . . . . 13 78 3.3.8. CERTIFICATE . . . . . . . . . . . . . . . . . . . . . 13 79 3.3.9. GETKEY . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.3.10. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 3.3.11. ROUTING . . . . . . . . . . . . . . . . . . . . . . . 14 82 3.3.12. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . 14 83 3.3.13. OBSCURE . . . . . . . . . . . . . . . . . . . . . . . 15 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 86 Appendix A. XML Schema Definition for Messages . . . . . . . . . 18 87 6. Normative References . . . . . . . . . . . . . . . . . . . . . 31 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 89 Intellectual Property and Copyright Statements . . . . . . . . . . 33 91 1. Introduction 93 Chat systems allow groups of people to exchange text messages and 94 even data like photos, documents, etc. in realtime within so-called 95 channels: While each participant of a channel can write messages to 96 that channel, he/she can also read all messages sent by other people 97 to the same channel. Besides messages, the user can enter commands 98 to his local chat application in order to join or leave channels, 99 list existing channels, etc. 101 Traditional chat systems are based on servers - either a single 102 server or a static network of servers. Each user has to connect to a 103 well-known server in order to start chat communication. In contrast 104 to that server approach, this document presents a peer-to-peer chat 105 architecture for Mobile Ad Hoc Networks (MANETs). This means that 106 all nodes in the chat network behave equally from the protocol point 107 of view. To establish the network of chat participants the nodes 108 just have to discover potential peers in their neighborhood. Since 109 mobile nodes leave and enter the network any time, the network 110 topology may change continuously and partitioned networks may have to 111 be merged. For this reason, the chat architecture has to be 112 disruption tolerant in order to handle such events. 114 1.1. Terminology 116 Node, Peer: A node is one active component in the chat network. Note 117 that there may be multiple nodes located on a common host. Note also 118 that one node may serve multiple local users. From the perspective 119 of one node and regarding a given link, the peer is the node at the 120 remote end of the link. 122 Link, connection: Two mobile nodes may be connected through a link if 123 they are in transmission range. Each link, once established, can be 124 used in both directions. Although the term "connection" is used to 125 indicate that two nodes are in transmission range and communicate 126 with each other, data is always exchanges via UDP which is not 127 connection-oriented. 129 Message: Data transferred between two nodes on a link is encoded in a 130 message. Messages are XML documents. See Section 3. 132 User, User ID: A user is a (typically) human participant in the chat 133 network. Each user has an unique ID which is typically equal to his/ 134 her email address, e.g. strauss@ibr.cs.tu-bs.de. 136 Channel, Channel ID: Communication is organized in channels. Each 137 user (not the node!) may subscribe to and unsubscribe from a channel 138 in order to control which text messages received at a node shall be 139 presented to that user. A channel is associated with a short one- 140 word pattern, e.g. "smalltalk" and a channel ID. The channel ID 141 consists of two parts separated by an "@". The last part MUST be the 142 local hostname. The generation of first part is an implementation 143 issue, but the nodes SHOULD use UUIDs (universally unique 144 identifier)[ITUX667]. In either case, the channel IDs MUST differ 145 from other known IDs. 147 Channel creator: Each user can create a new channel. 149 Public channel: Traffic on a public channel is not encrypted, thus 150 each user can join such a channel, read all messages on such a 151 channel and send text messages to such a channel. Public channels 152 can be identified by their channel name. 154 Closed channel: Closed channels are associated with a list of channel 155 members given by their user IDs. This list is initialized by the 156 channel creator and may be extended by each channel member. (This is 157 not a security risk, since each member can decode and forward the 158 traffic, anyway.) Closed channels MUST be identified by their 159 channel ID and their channel name. 161 Anonymous channel: The anonymous channel is omnipresent and allows 162 the users to post messages anonymously. Every active user is 163 automatically a member of this channel. The channel name "Anonymous" 164 is reserved for the anonymous channel and MUST NOT be used for other 165 channels. 167 Channel member: Participant of a channel. 169 Channel key: Messages to closed channels are encrypted using a common 170 symmetric channel key. The channel creator decides about the key 171 type and its parameters. The key is distributed through 172 asymmetrically encrypted key distribution messages to the channel 173 members. 175 Certificate: X.509 certificates are used to prove and verify user IDs 176 and to use their public keys to exchange the symmetric keys of closed 177 channels, verify messages and encrypt anonymous messages in the path- 178 obscuring phase. 180 Peer list: A list of communication partners that are assumed to be in 181 transmission range. This list is only used in infrastructure mode. 182 If a client operates in infrastructure mode, it will ignore all 183 messages received from nodes that are not listed on the local peer 184 list. 186 1.2. Terms of Requirement Levels 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 2. The Architecture 194 2.1. The Peer-to-Peer Network 196 The chat network is organized in a peer-to-peer overlay network that 197 is established within a mobile ad hoc network (MANET). Due to node 198 mobility in the underlying network, the topology of the peer-to-peer 199 network may change over time. In general the node MUST use the well- 200 known UDP port 8888 for its communication. Upon startup of a node, 201 it MUST start sending periodic HELLO messages. Moreover, it tries to 202 discover other peer nodes in its transmission range. This is done by 203 listening to HELLO messages sent by other peers in the network. 205 Each connection can be used symmetrically, i.e., messages can be sent 206 in both directions. The details of peer node and connection 207 management are an implementation issue. 209 2.2. Infrastructure Mode 211 The P2P Chat Protocol is designed for MANETs. However, there should 212 be a possibility to use the protocol in infrastructure networks. 213 Thus, each node MUST have a list of peer nodes (IPv4 and port) stored 214 in a persistent local storage which is called peer list further on. 215 This list explicitly defines the available links and is only used if 216 the peer runs in infrastructure mode. In this case it will ignore 217 all messages received from peers that are not listed on the local 218 peer list. The infrastructure mode may be used for establishing a 219 "virtual" overlay network for demonstration or testing purposes. 220 Since it should be possible to test several clients on a single host, 221 the port numbers in this list MAY differ from the well-known port. 222 Note that messages (especially broadcast messages) MAY have also be 223 sent to all nodes using a different port than the well-known one. 225 2.3. Mobility Issues 227 An important issue in MANETs is the mobility of communication 228 partners. Due to mobility, the topology of the network may change 229 continuously. It also may happen that the network becomes 230 partitioned into two or more independent networks and later re-merges 231 again. These characteristics also affect the communication in the 232 overlay peer-to-peer network, especially regarding to the channel 233 management. 235 If two MANETs merge due to mobility there may exist different 236 CHANNELs with the same name that were created independently. In the 237 case of public channels, these channels MUST be merged after the 238 separate networks became one. Each member of one of the channels 239 that discovers duplicate channels having the same channel name, MUST 240 send a new CHANNEL including the members of both previous channels. 241 The new channel ID of the merged CHANNEL MUST be the smallest ID of 242 the previous CHANNELs (in ASCII representation). Closed channels 243 MUST NOT be merged since for both channels there is an individual 244 shared secret. Thus, these channels (and the respective messages to 245 these channels) MUST be distinguished by their channel IDs. 247 2.4. Routing 249 Routing in a MANET is a challenging issue. Each chat message has 250 specific attributes like TTL and FLOOD that are used for routing 251 purposes (see Section 3.2). There are three different ways of 252 routing specific messages in the network. 254 Some messages (ACK, HELLO, QUIT, ROUTING) are only sent from a 255 sending node to a neighboring peer node without further forwarding. 256 These messages MUST be sent with ttl="1" and with flood="false" (see 257 Section 3.2 for further information on ttl and flood). 259 Some messages (GETCERTIFICATE, CERTIFICATE, GETKEY, KEY, MESSAGE, 260 OBSCURE, NACK) are multicasted to a set of receivers (maybe one, 261 i.e., unicast). In this case the message is sent with an initial 262 value of e.g. ttl="32" and with flood="false". The selection of an 263 appropriate ttl value is an implementation issue. The message 264 contains an according "receiver" element for every receiver, i.e. it 265 is a so called explicit multicast. When a node receives such a 266 message, it MUST acknowledge the reception to the previous hop by 267 sending an ACK message. Afterwards, it can recognize any local users 268 for whom the message has to be processed, and it also has to forward 269 the message to any remaining receivers. To do this, the routing 270 table is used to determine the appropriate outgoing links and to 271 filter the set of remaining receivers that can be reached on the 272 shortest paths on those outgoing links (the list of remaining 273 receivers SHOULD only include the IDs of that users that can be 274 reached over the specific link). Updates to the routing table are 275 calculated based on the current state of the table and subsequently 276 received ROUTING messages (Section 3.3.11). A message's ttl may 277 becomes zero on its way to the destinations. In this case, the node 278 that holds the message has to inform the source node of that message 279 about the fact that the message has not reached all receivers by 280 sending a NACK message. 282 Some messages (CHANNEL, JOIN, LEAVE, MESSAGE in case of anonymous 283 messages) are flooded to the whole network. In this case the message 284 is sent with an initial value of e.g. ttl="32" and with flood="true". 285 Note that the TTL value of CHANNEL messages MUST be lower than the 286 minimal channel announcement interval (see Section 3.3.4). The 287 selection of an appropriate ttl value is an implementation issue. If 288 a peer receives a flooded message for the second time, which can be 289 recognized through the message ID and a ring buffer backlog of 290 received message IDs, the message MUST be dropped. 292 Message forwarding MUST always be done in a hop-by-hop manner. This 293 means that each hop is responsible for delivering the message to the 294 next hop on the path to the destination. For each multicasted 295 message (GETCERTIFICATE, CERTIFICATE, GETKEY, KEY, MESSAGE, OBSCURE) 296 the peer can be sure that the message reached the next hop if it 297 received an ACK for the respective message. If a peer detects a 298 route failure (if it receives no ACK from the next hop for that 299 message), it MUST find an alternative way to deliver the packet 300 towards the destination. For this, it e.g. may immediately try to 301 find an alternative route to the destination or cache the message for 302 some time and try it later again. The concrete stragegy is an 303 implementation issue. If a message's TTL expires while the message 304 is cached, the node MUST send a NACK message to the sender of the 305 message and drop the original message. 307 2.5. Security 309 In order to support signed messages, closed channel communication and 310 anonymous communication, a user MUST have an RSA keypair, the 311 keylength being 1024 bit. In order to be able to prove his/her 312 identity each user must have an X.509 certificate for his/her public 313 key. 315 Signing of the messages SHOULD always be done with the exception of 316 anonymous messages. The mandatory algorithms are MD5 with RSA. The 317 concatenation of all text sub-nodes of the message starting at the 318 message type node, but excluding any receiver elements, form the 319 input to the signing process (see the XML Schema definition in 320 Appendix A for further details). 322 All messages of a closed channel MUST be encrypted using symmetric 323 cryptography. Therefore, the creator of a closed channel generates a 324 shared secret key which is encrypted and sent to all participants 325 (upon request and optionally in advance) using the respective public 326 key of each participant. The RSA encryption MUST use the Electronic 327 Code Book (ECB) mode with the padding scheme PKCS1 (v1.5). The 328 mandatory symmetric algorithm is standard 64 (56) bit DES in Cipher 329 Block Chaining (CBC) mode with the padding scheme PKCS5 enabled. 330 Further symmetric algorithms may be added in the future. Note: Only 331 the content of the text element in a MESSAGE message is encrypted. 332 If the message contains one or more attachments, the content of the 333 filename, applicationtype, and data elements is encrypted 334 individually. (see the XML Schema definition in Appendix A for 335 further details). 337 2.6. Anonymous Communication 339 In order to allow anonymous posting of messages, an anonymous channel 340 is supported. This channel is omnipresent, i.e., does not need 341 channel announcements, does not die etc. Each active user is 342 automatically a member of it. The channel name "Anonymous" is 343 reserved for the anonymous channel and MUST NOT be used for other 344 channels. 346 Anonymous communication consists of two phases: the path-obscuring 347 and the posting of the message. 349 In the beginning, the sender creates a list of at least 3 and up to 5 350 random active users, which help in obscuring the path and thus the 351 sender's identity. The MESSAGE message that the sender wants to post 352 MUST be encrypted with the public key of the last user in the list 353 (RSA in ECB mode with PKCS1 (v1.5) padding). This data forms the 354 content of the OBSCURE message that is destined at the last user. 355 This OBSCURE message is then again encrypted with the public key of 356 the last but one user in the list and forms the content of another 357 OBSCURE message, which is destined at that user. This scheme MUST be 358 repeated until the list is empty. The final OBSCURE message, is sent 359 to the first user in the list. 361 Upon reception of an OBSCURE message at its target node, the content 362 MUST be decrypted. If the decrypted message content is another 363 OBSCURE message it MUST be sent on to the receiver that is already 364 placed in the message. In case of the decrypted message being the 365 message to be posted, it MUST be flooded to the network. 367 In order to prevent message loss during the path-obscuring phase, the 368 original sender SHOULD resend the message if it has not been posted 369 to the anonymous channel after a timeout. In this case, the sender 370 SHOULD create a different list of active users and encrypt the 371 message according to the above defined rules. 373 3. The Protocol 375 This section describes the peer-to-peer chat protocol version 2. 377 3.1. Protocol Message Format 379 Each message represents a well-formed XML [XML] document. Each 380 message MUST be sent to its destination in an individual UDP datagram 381 [RFC768]. It is not allowed to put several messages in a single 382 datagram. The maximum message size is limited to 63000 bytes. Only 383 NACK messages are allowed to exceed this limit. Each message 384 (including NACKs) MUST fit into one UDP datagram. It is not be 385 possible to split up messages over several datagrams. 387 An XML Schema definition for messages is given in Appendix A. 389 3.2. Protocol Message Exchange 391 Every message is of a specific message type given by the one and only 392 direct child element of the root element of the message XML document. 393 All protocol messages are handled asynchronously, i.e., a node MUST 394 NOT block and wait for a certain reply message when a request message 395 was sent. 397 Each chat message contains two attributes used for routing purposes: 398 TTL and FLOOD. The TTL value of each message MUST be decremented on 399 each hop as well as for every full second a message is held on a node 400 before it is forwarded to the next hop. Note that the initial TTL 401 values are mandatory, since they may be used to derive routing 402 information. The FLOOD flag indicated whether a message MUST be 403 flooded through the network. 405 In addition, messages MAY contain a DELAY attribute that states the 406 cumulative queuing time in seconds at all intermediate nodes. This 407 value is incremented for every second a packet is queued on an 408 intermediate node for any reason. This value can be used to 409 determine messages with high delays. 411 3.3. Protocol Messages 413 This section describes all protocol message types. The named message 414 types are equal to the name of the one and only direct child element 415 of the corresponding "chat-message" root element. Note that message 416 types are just written all caps in this document for readability. 418 3.3.1. HELLO 420 The HELLO message MUST be sent periodically by each node. The 421 interval between two successive HELLO messages MUST be 2 seconds +/- 422 0.5 seconds. A peer SHOULD choose a new interval randomly between 423 1.5 and 2.5 seconds for each individual beacon in order to reduce the 424 collision probability. The HELLO message can be used to detect other 425 peers in the local neighborhood. If no further HELLO message is 426 received for three successive HELLO intervals, the remote node may be 427 moved out of the transmission range. 429 3.3.2. ACK 431 An ACK message MUST be sent in response to a GETCERTIFICATE, 432 CERTIFICATE, GETKEY, KEY, MESSAGE or OBSCURE message. The message 433 informs the sender or forwarder of a message that this message has 434 arrived at the next hop. It MUST include the message ID of the 435 received message. 437 3.3.3. NACK 439 A NACK message MUST be sent if the TTL of a message becomes zero on 440 the way to the destinations. It is used to inform the original 441 sender about the fact that its message has not received all 442 destinations. The actions that are taken by a node that receives a 443 NACK for one of its messages sent is an implementation issue. The 444 NACK message MUST only be sent to the original sender of the message. 445 Moreover, it MUST include the whole original message. In addition, a 446 NACK messages includes the user ID of its sender and a unique message 447 ID. 449 3.3.4. CHANNEL 451 A CHANNEL message for a specific channel is sent 453 o once when a local user creates a channel, 455 o when the node did not receive a CHANNEL message for the channel 456 for a certain time and as long as a local user is still subscribed 457 to that channel. This time SHOULD be a random value in the range 458 between 50 and 60 seconds. 460 o Furthermore, CHANNEL messages MIGHT be sent once for each known 461 channel to a newly connected peer node. 463 This ensures that channels keep alive and known (including the 464 subscribers) to all nodes. A CHANNEL message SHOULD be sent with 465 ttl="32". The TTL value MUST be lower than the minimal channel 466 announcement interval. The CHANNEL message is always flooded to the 467 whole network. 469 Each channel is identified by a channel name and a channel ID. The 470 name of a new channel MUST differ from the names of existing 471 channels. While the name is a descriptive identifier for a channel, 472 each channel also has a unique channel ID that MUST differ from other 473 known IDs and SHOULD be generated according to Section 1.1. If a 474 node recognizes two channels with the same names, they have to be 475 handled according to Section 2.3. 477 The CHANNEL message always contains the list of subscribed channel 478 members. Only these users are allowed to send messages to the 479 channel. Messages for a specific channel coming from other users 480 MUST be ignored. Nevertheless, a node MAY wait for the next channel 481 announcement before dropping the message. In case of a closed 482 channel only the users in the subscription list of the CHANNEL 483 message are allowed to retrieve the session key through a GETKEY/KEY 484 message pair. Users of a closed channel are allowed to add further 485 members to the list by sending a new CHANNEL message with the 486 extended list. CHANNEL messages of closed channels MUST be signed by 487 the sender to prevent non-members from adding themselves or other 488 users to the list.There is no way to reduce the members list of 489 closed channels, since it is obviously not possible to revoke a 490 shared secret. 492 Note that a public channel cannot later be turned into a closed 493 channel. There is no way to actively close or remove a channel. A 494 channel is "gone", when there are no more nodes that send regular 495 CHANNEL messages. 497 3.3.5. JOIN 499 A node sends a JOIN message 501 o once when a local user subscribes to a channel, 503 o when a local user is already subscribed to a channel for which a 504 CHANNEL message is received that does not (yet) list that local 505 user. 507 The JOIN message is always flooded to the whole network. 509 3.3.6. LEAVE 511 A node sends a LEAVE message 512 o once when a local user unsubscribes from a channel, 514 o when a local user is not subscribed to a channel for which a 515 CHANNEL message is received that does (still) list that local 516 user. 518 The LEAVE message is always flooded to the whole network. 520 3.3.7. GETCERTIFICATE 522 A node may request a certificate for a given user ID by sending a 523 GETCERTIFICATE message. This is usually caused by the wish to verify 524 the signature of a received message, when the according certificate 525 is not yet available at the local node. Note that the sender of the 526 GETCERTIFICATE (and the receiver of the response) is identified by a 527 user ID although certificates may be used to serve all users at the 528 local node. 530 3.3.8. CERTIFICATE 532 A node can send a certificate encapsulated in a CERTIFICATE message. 533 This MAY be done in advance (e.g., to all channel members before 534 sending a signed message to a channel) to avoid subsequent 535 GETCERTIFICATE/CERTIFICATE message traffic. Furthermore, a 536 CERTIFICATE message MUST be sent in response to a received 537 GETCERTIFICATE message for a local user. An intermediate node MAY 538 also send a CERTIFICATE message in response to a GETCERTIFICATE 539 message if it has the certificate of the requested user in its local 540 cache. In this case, it MUST NOT forward the GETCERTIFICATE message 541 along the route to the destination. 543 3.3.9. GETKEY 545 A node may request a channel key for a given closed channel by 546 sending a GETKEY message to the one member that sent and signed the 547 channel announcement. This MUST only be done if a previous CHANNEL 548 message has been received and the local user's ID is on the members 549 list of that channel. 551 If a GETKEY message is received and a KEY response (see below) can be 552 sent, the GETKEY message MUST be dropped and not forwarded to any 553 other receivers. 555 3.3.10. KEY 557 A node MUST send a channel key encapsulated in a KEY message in 558 response to a GETKEY message sent to the local user. The key MUST be 559 encrypted for that user. The sender MUST be sure that the receiver 560 is a member of the closed channel and the public key used for the key 561 encryption really belongs to the receiver. This is usually done 562 through a certificate verification process. 564 3.3.11. ROUTING 566 A node MUST send a ROUTING message on a regular basis to all its 567 neighboring peers. Each entry of the ROUTING message represents a 568 known user and signals the number of hops it takes to reach that 569 user, i.e., the receiver of the ROUTING message can subsequently 570 reach those users via that link with n+1 hops. 572 The interval to send ROUTING messages SHOULD be chosen randomly from 573 the interval [8,10] seconds. Additionally, the node MIGHT send 574 ROUTING messages upon changes to the local routing table, but it MUST 575 NOT send more than one message per second. 577 Note that a node MIGHT also "learn" additional routing information 578 based on other messages than ROUTING messages through the sender and 579 TTL values. 581 3.3.12. MESSAGE 583 The users' text messages within channels are distributed in MESSAGE 584 messages. With the exception of anonymous MESSAGE messages, the 585 initial sender of a MESSAGE message MUST put all members of the 586 channel into the receivers list. A MESSAGE message MAY contain one 587 or more attachments. The attached data MUST be Base64 encoded. An 588 attached file is described by a filename and the application MIME 589 type [RFC2045][RFC2046]. In case of a closed channel, the content of 590 messages MUST be sent encrypted with the channel key (which probably 591 must be retrieved through a GETKEY/KEY conversation first). 593 Each MESSAGE message contains a UTC timestamp which is generated by 594 the original sender. This timestamp MAY be used to put the received 595 message into the context of a discussion. Note that there is 596 typically no global time in a MANET. Therefore, this timestamp 597 depends on the peer sending the message and timestamps from different 598 peers MAY NOT be consistent. 600 A MESSAGE message MUST NOT exceed the packet size limit mentioned in 601 Section 3.1 603 A node that receives a MESSAGE message MUST forward the message on 604 each link (except the incoming link) on which it can reach at least 605 one of the receivers through the shortest path. All receivers for 606 which the link does not supply the shortest path are removed before 607 forwarding. 609 In case of the MESSAGE message being the final message of an 610 anonymization chain, its message ID MUST be inserted by the sender of 611 the message, and the anonymous originator MUST NOT have placed a 612 message ID in the message. Furthermore, the message MUST be destined 613 at the channel 'Anonymous'. 615 3.3.13. OBSCURE 617 An OBSCURE message is an anonymous message in the path- obscuring 618 phase. The content MUST contain another OBSCURE message or a MESSAGE 619 message which MUST be encrypted with the receiver's public key. 621 A node that receives an OBSCURE message MUST decrypt the content with 622 its private key and MUST send on the resulting message in a new chat 623 message. 625 The message ID of an OBSCURE message MUST be inserted by its 626 immediate sender, i.e., not the initial creator of the OBSCURE 627 message chain. 629 An OBSCURE message MUST NOT exceed the packet size limit mentioned in 630 Section 3.1 632 4. Security Considerations 634 This document defines an application protocol to carry potentially 635 private or authentic information. The protocol addresses these needs 636 through the application of strong cryptographic digest and encryption 637 algorithms. X.509 certificates are used to verify identities of end 638 users. This document requires implementations to support a minimal 639 common set of cryptographic algorithms so that from the 640 specifications point of view secure communication can be guaranteed. 641 However, anonymous communication makes assumptions that cannot be 642 always guaranteed, i.e. an attacker is not able to trace the complete 643 path an anonymous message takes before being posted to the anonymous 644 channel. 646 At the current status the protocol takes no measures to protect 647 against DoS attacks by peers. 649 5. Acknowledgements 651 The protocol described in this memo is the output of a practical 652 course on distributed systems that has been conducted during two 653 terms at Technische Universitaet Braunschweig in April - July, 2003 654 and in the same summer term in 2004. A first step of the work 655 presented here has been developed by the approx. 48 participating 656 students of the first course in 2003 during a two-weeks design phase 657 and a subsequent protocol design colloquium. Then the second course 658 in 2004 improved routing concepts significantly and added anonymous 659 communication in a similar design and colloquium way. In 2007 the 660 protocol has been extended to support mobility issues in Wireless Ad 661 Hoc Networks. Thus, the transport protocol has be switched from TCP 662 to UDP. In addition, several changes regarding neighbour discovery, 663 disruption tolerance, and node mobility were introduced. The 664 extended protocol is the basis for a practical course on software 665 engeneering at Technische Universitaet Braunschweig in April - July 666 2007 668 The authors of this memo are basically the editors who have put the 669 design decisions together in a common specification document along 670 with some refinements and mobility support. Hence, the authors' 671 thanks go to all the ambitious students of the summer 2003 and summer 672 2004 PVS courses. 674 Appendix A. XML Schema Definition for Messages 676 678 682 690 691 692 This XML Schema defines the p2p-chat protocol messages. 693 694 696 700 701 702 703 Elements of this type represent a globally unique user 704 identification. It has to contain a user name part followed by 705 an @ character and a domain part. It is highly recommended to 706 use the users valid Internet email address. Note that it has 707 to be treated case-insensitive. 708 709 710 711 713 714 716 717 718 719 Elements of this type are used to form a unique identification 720 for messages per user. The pair of a UserID and a MessageID 721 builds a globally unique message identification. How the 722 MessageID is actually built is an implementation issue. It 723 might be a persistent counter incremented with each message 724 generation, or it might be based on a timestamp, for example. 725 726 727 728 729 730 732 733 734 735 Elements of this type are used to form a unique identification 736 for channels. The pair of a channel name and a channelID 737 builds a globally unique channel identification. How the 738 channelID is actually built is an implementation issue. The 739 channelID MUST differ from other known IDs. Is consists of two 740 parts sperarated by an "@". The first part SHOULD be 741 generated randomly on the basis of UUIDs. The second part is 742 the name of the local host. 743 744 745 746 748 749 751 752 753 754 An integer time-to-live value. Note that the value range is 755 restricted. 756 757 758 759 760 761 762 764 765 766 767 The name of a channel. Note that it has to be treated 768 case-insensitive. The name "Anonymous" is reserved 769 for the 770 anonymous channel and MUST NOT be used for other channels. 771 772 773 774 775 776 778 779 780 781 A destination is part of a routing message. It signals 782 the number of hops to reach a user via the link on which 783 the routing message is sent. 784 785 786 787 789 791 792 794 795 796 797 A certificate consists of the user ID to which the certificate 798 belongs and the certificate itself encoded in Base64. 799 800 801 802 804 806 807 809 810 811 812 A message attachment. The applicationtype states the MIME Type 813 of the attached file. 815 The application data MUST always be Base64 encoded. 816 If the iv attribute is present, 817 it is a message of a closed channel and uses the 818 initialization 819 vector given by the iv attribute. The content of all elements 820 MUST be de-/encrypted individually. 821 822 823 824 826 828 830 831 833 835 836 837 838 A label to identify a symmetric cipher algorithm. So far, 839 just one (reasonable) cipher is defined, but others may be 840 added in future revision of the protocol. 841 842 843 844 845 846 847 No encryption. 848 849 850 851 852 853 854 64(56) bit DES in Cipher Block Chaining mode with PKCS #5 855 padding. 856 857 858 859 860 861 862 863 864 A label to identify a message digest algorithm. So far, just 865 one algorithm is defined, but others may be added in future 866 revision of the protocol. 867 868 869 870 871 872 873 MD5 digest (encrypted with the senders private key). 874 875 876 877 878 880 881 882 883 A Base64 encoded signature. It is calculated for the 884 concatenated UTF-8 encoded values (without attributes) of all 885 child elements of the chat-message element in depth-first 886 order. 887 888 889 890 892 896 899 900 901 902 This element represents a p2p-chat protocol 903 message. 904 905 906 907 908 910 912 914 916 918 920 922 924 926 928 930 932 934 935 936 939 942 945 947 949 951 952 953 954 The "hello" message is the first message sent by 955 each peer of 956 a newly established connection. The peer may send an informal 957 greeting text. A HELLO message MAY contain more than one 958 sender 959 if a node serves more than one user. 960 961 962 963 966 968 970 972 973 975 976 977 978 The "ack" message is sent by a peer that receives a 979 multicasted 980 message from another peer in order to inform the sender that 981 this message reached the next hop. It always includes the ID 982 of the received message. 983 984 985 986 988 990 991 993 994 995 996 The "Nack" message is sent by a peer that receives a 997 multicasted 998 message from another peer and is not able to forward it 999 towards its destination. The "Nack" message is 1000 always sent to 1001 the original source of that message and informs the sender 1002 that its message has not received its destination. The 1003 original message has to be attached to the "Nack". 1004 1005 1006 1007 1009 1011 1013 1014 1016 1017 1018 1019 The "channel" message announces an active channel. 1020 The 1021 "closed" flag denotes whether it is a closed 1022 channel. 1023 Each known subscriber is listed in a "member" child 1024 element. 1025 1026 1027 1028 1030 1032 1034 1036 1038 1041 1042 1045 1047 1048 1049 1050 The "join" message signal the subscription of a user 1051 to 1052 a non-closed channel. 1053 1054 1055 1056 1058 1060 1062 1064 1065 1067 1068 1069 1070 The "leave" message signal the unsubscription of a 1071 user from 1072 a non-closed channel. 1073 1074 1075 1076 1078 1080 1082 1084 1085 1087 1088 1089 1090 A node may send a "getcertificate" message to 1091 request a 1092 certificate for a given user ID. 1093 1094 1095 1096 1098 1100 1102 1103 1105 1106 1107 1108 A node can send a certificate encapsulated in 1109 a "certificate" message. It's not only the 1110 owner of 1111 the certificate who can send such a message. 1112 1113 1114 1115 1117 1120 1122 1124 1125 1127 1128 1129 1130 A node may request a channel key for a given closed channel 1131 through a "getkey" message. 1132 1133 1134 1135 1137 1139 1141 1143 1146 1147 1149 1150 1151 1152 A node can send a channel key encapsulated in a 1153 "key" 1154 message. The actual data part of the key has to be encrypted 1155 with the according receiver's public key. It is the duty 1156 of 1157 the sender of a "key" message to ensure that the 1158 public key 1159 really belongs to the receiver and that the receiver is 1160 really a member of the channel. 1161 1162 1163 1164 1166 1168 1170 1172 1174 1176 1178 1179 1181 1182 1183 1184 Routing messages are exchanged on links to form a converging 1185 knowledge on the network topology on every node. 1186 1187 1188 1189 1191 1195 1196 1198 1199 1200 1201 The "message" message carries the actual content of 1202 the chat 1203 message in its text element. If the iv attribute is present 1204 it is a message of a closed channel and uses the 1205 initialization 1206 vector given by the iv attribute. 1207 1208 1209 1210 1213 1216 1219 1221 1224 1227 1228 1229 1230 1231 1233 1234 1235 1236 1237 1240 1241 1242 1243 1244 1245 The "obscure" is created by a user who intends to 1246 emit a 1247 "message" message but remain anonymous as the sender 1248 of the 1249 message. The "text" payload is in turn an 1250 "obscure" message 1251 or a "message" message after decryption. 1252 1253 1254 1255 1257 1260 1262 1263 1265 1267 6. Normative References 1269 [ITUX667] International Telecommunication Union (ITU-T), 1270 "Information technology - Open Systems Interconnection - 1271 Procedures for the operation of OSI Registration 1272 Authorities: Generation and registration of Universally 1273 Unique Identifiers (UUIDs) and their use as ASN.1 Object 1274 Identifier components", Rec X.667, September 2004. 1276 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, 1277 August 1980. 1279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", RFC 2119, BCP 14, March 1997. 1282 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1283 Extensions (MIME) Part One: Format of Internet Message 1284 Bodies", RFC 2045, November 1996. 1286 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1287 Extensions (MIME) Part Two: Media Types", RFC 2046, 1288 November 1996. 1290 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1291 Specifications: ABNF", RFC 2234, November 1997. 1293 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 1294 "Extensible Markup Language (XML) 1.0 (Second Edition)", 1295 W3C Recommendation 1, October 2000. 1297 Authors' Addresses 1299 Frank Strauss 1300 TU Braunschweig 1301 Muehlenpfordtstrasse 23 1302 38106 Braunschweig 1303 Germany 1305 Phone: +49 531 391-3268 1306 Email: strauss@ibr.cs.tu-bs.de 1307 URI: http://www.ibr.cs.tu-bs.de/ 1309 Stefan Ransom 1310 Universitaet zu Luebeck 1311 Ratzeburger Allee 160 1312 23538 Luebeck 1313 Germany 1315 Phone: +49 451 500-5385 1316 Email: ransom@itm.uni-luebeck.de 1317 URI: http://www.itm.uni-luebeck.de/ 1319 Sven Lahde 1320 TU Braunschweig 1321 Muehlenpfordtstrasse 23 1322 38106 Braunschweig 1323 Germany 1325 Phone: +49 531 391-3264 1326 Email: lahde@ibr.cs.tu-bs.de 1327 URI: http://www.ibr.cs.tu-bs.de/ 1329 Oliver Wellnitz 1330 TU Braunschweig 1331 Muehlenpfordtstrasse 23 1332 38106 Braunschweig 1333 Germany 1335 Phone: +49 531 391-3266 1336 Email: wellnitz@ibr.cs.tu-bs.de 1337 URI: http://www.ibr.cs.tu-bs.de/ 1339 Full Copyright Statement 1341 Copyright (C) The IETF Trust (2007). 1343 This document is subject to the rights, licenses and restrictions 1344 contained in BCP 78, and except as set forth therein, the authors 1345 retain all their rights. 1347 This document and the information contained herein are provided on an 1348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1350 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1351 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1355 Intellectual Property 1357 The IETF takes no position regarding the validity or scope of any 1358 Intellectual Property Rights or other rights that might be claimed to 1359 pertain to the implementation or use of the technology described in 1360 this document or the extent to which any license under such rights 1361 might or might not be available; nor does it represent that it has 1362 made any independent effort to identify any such rights. Information 1363 on the procedures with respect to rights in RFC documents can be 1364 found in BCP 78 and BCP 79. 1366 Copies of IPR disclosures made to the IETF Secretariat and any 1367 assurances of licenses to be made available, or the result of an 1368 attempt made to obtain a general license or permission for the use of 1369 such proprietary rights by implementers or users of this 1370 specification can be obtained from the IETF on-line IPR repository at 1371 http://www.ietf.org/ipr. 1373 The IETF invites any interested party to bring to its attention any 1374 copyrights, patents or patent applications, or other proprietary 1375 rights that may cover technology that may be required to implement 1376 this standard. Please address the information to the IETF at 1377 ietf-ipr@ietf.org. 1379 Acknowledgment 1381 Funding for the RFC Editor function is provided by the IETF 1382 Administrative Support Activity (IASA).