Network Working Group F. Strauss
Internet-Draft TU Braunschweig
Expires: October 3, 2007 S. Ransom
Universitaet zu Luebeck
S. Lahde
O. Wellnitz
TU Braunschweig
April 2007
P2P CHAT - A Peer-to-Peer Chat Protocol
draft-strauss-p2p-chat-08
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Strauss, et al. Expires October 3, 2007 [Page 1]
Internet-Draft P2P Chat Protocol April 2007
Abstract
This memo presents the third version of a protocol for a peer-to-peer
based chat system. In this version it is extended for supporting
message exchange in Mobile Ad Hoc Networks (MANETs) that suffer from
node mobility. Messages can be cryptographically signed, encrypted
and anonymized allowing authentic and closed group communication as
well as anonymous communication. This work is input for a practical
course on software engineering at Technische Universitaet
Braunschweig. It is experimental work that is not intended to go to
the IETF standards track.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terms of Requirement Levels . . . . . . . . . . . . . . . 5
2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. The Peer-to-Peer Network . . . . . . . . . . . . . . . . . 6
2.2. Infrastructure Mode . . . . . . . . . . . . . . . . . . . 6
2.3. Mobility Issues . . . . . . . . . . . . . . . . . . . . . 6
2.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Anonymous Communication . . . . . . . . . . . . . . . . . 9
3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Protocol Message Format . . . . . . . . . . . . . . . . . 10
3.2. Protocol Message Exchange . . . . . . . . . . . . . . . . 10
3.3. Protocol Messages . . . . . . . . . . . . . . . . . . . . 10
3.3.1. HELLO . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3. NACK . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.4. CHANNEL . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.5. JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.6. LEAVE . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.7. GETCERTIFICATE . . . . . . . . . . . . . . . . . . . . 13
3.3.8. CERTIFICATE . . . . . . . . . . . . . . . . . . . . . 13
3.3.9. GETKEY . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.10. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.11. ROUTING . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.12. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.13. OBSCURE . . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. XML Schema Definition for Messages . . . . . . . . . 18
6. Normative References . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Strauss, et al. Expires October 3, 2007 [Page 2]
Internet-Draft P2P Chat Protocol April 2007
1. Introduction
Chat systems allow groups of people to exchange text messages and
even data like photos, documents, etc. in realtime within so-called
channels: While each participant of a channel can write messages to
that channel, he/she can also read all messages sent by other people
to the same channel. Besides messages, the user can enter commands
to his local chat application in order to join or leave channels,
list existing channels, etc.
Traditional chat systems are based on servers - either a single
server or a static network of servers. Each user has to connect to a
well-known server in order to start chat communication. In contrast
to that server approach, this document presents a peer-to-peer chat
architecture for Mobile Ad Hoc Networks (MANETs). This means that
all nodes in the chat network behave equally from the protocol point
of view. To establish the network of chat participants the nodes
just have to discover potential peers in their neighborhood. Since
mobile nodes leave and enter the network any time, the network
topology may change continuously and partitioned networks may have to
be merged. For this reason, the chat architecture has to be
disruption tolerant in order to handle such events.
1.1. Terminology
Node, Peer: A node is one active component in the chat network. Note
that there may be multiple nodes located on a common host. Note also
that one node may serve multiple local users. From the perspective
of one node and regarding a given link, the peer is the node at the
remote end of the link.
Link, connection: Two mobile nodes may be connected through a link if
they are in transmission range. Each link, once established, can be
used in both directions. Although the term "connection" is used to
indicate that two nodes are in transmission range and communicate
with each other, data is always exchanges via UDP which is not
connection-oriented.
Message: Data transferred between two nodes on a link is encoded in a
message. Messages are XML documents. See Section 3.
User, User ID: A user is a (typically) human participant in the chat
network. Each user has an unique ID which is typically equal to his/
her email address, e.g. strauss@ibr.cs.tu-bs.de.
Channel, Channel ID: Communication is organized in channels. Each
user (not the node!) may subscribe to and unsubscribe from a channel
in order to control which text messages received at a node shall be
Strauss, et al. Expires October 3, 2007 [Page 3]
Internet-Draft P2P Chat Protocol April 2007
presented to that user. A channel is associated with a short one-
word pattern, e.g. "smalltalk" and a channel ID. The channel ID
consists of two parts separated by an "@". The last part MUST be the
local hostname. The generation of first part is an implementation
issue, but the nodes SHOULD use UUIDs (universally unique
identifier)[ITUX667]. In either case, the channel IDs MUST differ
from other known IDs.
Channel creator: Each user can create a new channel.
Public channel: Traffic on a public channel is not encrypted, thus
each user can join such a channel, read all messages on such a
channel and send text messages to such a channel. Public channels
can be identified by their channel name.
Closed channel: Closed channels are associated with a list of channel
members given by their user IDs. This list is initialized by the
channel creator and may be extended by each channel member. (This is
not a security risk, since each member can decode and forward the
traffic, anyway.) Closed channels MUST be identified by their
channel ID and their channel name.
Anonymous channel: The anonymous channel is omnipresent and allows
the users to post messages anonymously. Every active user is
automatically a member of this channel. The channel name "Anonymous"
is reserved for the anonymous channel and MUST NOT be used for other
channels.
Channel member: Participant of a channel.
Channel key: Messages to closed channels are encrypted using a common
symmetric channel key. The channel creator decides about the key
type and its parameters. The key is distributed through
asymmetrically encrypted key distribution messages to the channel
members.
Certificate: X.509 certificates are used to prove and verify user IDs
and to use their public keys to exchange the symmetric keys of closed
channels, verify messages and encrypt anonymous messages in the path-
obscuring phase.
Peer list: A list of communication partners that are assumed to be in
transmission range. This list is only used in infrastructure mode.
If a client operates in infrastructure mode, it will ignore all
messages received from nodes that are not listed on the local peer
list.
Strauss, et al. Expires October 3, 2007 [Page 4]
Internet-Draft P2P Chat Protocol April 2007
1.2. Terms of Requirement Levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Strauss, et al. Expires October 3, 2007 [Page 5]
Internet-Draft P2P Chat Protocol April 2007
2. The Architecture
2.1. The Peer-to-Peer Network
The chat network is organized in a peer-to-peer overlay network that
is established within a mobile ad hoc network (MANET). Due to node
mobility in the underlying network, the topology of the peer-to-peer
network may change over time. In general the node MUST use the well-
known UDP port 8888 for its communication. Upon startup of a node,
it MUST start sending periodic HELLO messages. Moreover, it tries to
discover other peer nodes in its transmission range. This is done by
listening to HELLO messages sent by other peers in the network.
Each connection can be used symmetrically, i.e., messages can be sent
in both directions. The details of peer node and connection
management are an implementation issue.
2.2. Infrastructure Mode
The P2P Chat Protocol is designed for MANETs. However, there should
be a possibility to use the protocol in infrastructure networks.
Thus, each node MUST have a list of peer nodes (IPv4 and port) stored
in a persistent local storage which is called peer list further on.
This list explicitly defines the available links and is only used if
the peer runs in infrastructure mode. In this case it will ignore
all messages received from peers that are not listed on the local
peer list. The infrastructure mode may be used for establishing a
"virtual" overlay network for demonstration or testing purposes.
Since it should be possible to test several clients on a single host,
the port numbers in this list MAY differ from the well-known port.
Note that messages (especially broadcast messages) MAY have also be
sent to all nodes using a different port than the well-known one.
2.3. Mobility Issues
An important issue in MANETs is the mobility of communication
partners. Due to mobility, the topology of the network may change
continuously. It also may happen that the network becomes
partitioned into two or more independent networks and later re-merges
again. These characteristics also affect the communication in the
overlay peer-to-peer network, especially regarding to the channel
management.
If two MANETs merge due to mobility there may exist different
CHANNELs with the same name that were created independently. In the
case of public channels, these channels MUST be merged after the
separate networks became one. Each member of one of the channels
that discovers duplicate channels having the same channel name, MUST
Strauss, et al. Expires October 3, 2007 [Page 6]
Internet-Draft P2P Chat Protocol April 2007
send a new CHANNEL including the members of both previous channels.
The new channel ID of the merged CHANNEL MUST be the smallest ID of
the previous CHANNELs (in ASCII representation). Closed channels
MUST NOT be merged since for both channels there is an individual
shared secret. Thus, these channels (and the respective messages to
these channels) MUST be distinguished by their channel IDs.
2.4. Routing
Routing in a MANET is a challenging issue. Each chat message has
specific attributes like TTL and FLOOD that are used for routing
purposes (see Section 3.2). There are three different ways of
routing specific messages in the network.
Some messages (ACK, HELLO, QUIT, ROUTING) are only sent from a
sending node to a neighboring peer node without further forwarding.
These messages MUST be sent with ttl="1" and with flood="false" (see
Section 3.2 for further information on ttl and flood).
Some messages (GETCERTIFICATE, CERTIFICATE, GETKEY, KEY, MESSAGE,
OBSCURE, NACK) are multicasted to a set of receivers (maybe one,
i.e., unicast). In this case the message is sent with an initial
value of e.g. ttl="32" and with flood="false". The selection of an
appropriate ttl value is an implementation issue. The message
contains an according "receiver" element for every receiver, i.e. it
is a so called explicit multicast. When a node receives such a
message, it MUST acknowledge the reception to the previous hop by
sending an ACK message. Afterwards, it can recognize any local users
for whom the message has to be processed, and it also has to forward
the message to any remaining receivers. To do this, the routing
table is used to determine the appropriate outgoing links and to
filter the set of remaining receivers that can be reached on the
shortest paths on those outgoing links (the list of remaining
receivers SHOULD only include the IDs of that users that can be
reached over the specific link). Updates to the routing table are
calculated based on the current state of the table and subsequently
received ROUTING messages (Section 3.3.11). A message's ttl may
becomes zero on its way to the destinations. In this case, the node
that holds the message has to inform the source node of that message
about the fact that the message has not reached all receivers by
sending a NACK message.
Some messages (CHANNEL, JOIN, LEAVE, MESSAGE in case of anonymous
messages) are flooded to the whole network. In this case the message
is sent with an initial value of e.g. ttl="32" and with flood="true".
Note that the TTL value of CHANNEL messages MUST be lower than the
minimal channel announcement interval (see Section 3.3.4). The
selection of an appropriate ttl value is an implementation issue. If
Strauss, et al. Expires October 3, 2007 [Page 7]
Internet-Draft P2P Chat Protocol April 2007
a peer receives a flooded message for the second time, which can be
recognized through the message ID and a ring buffer backlog of
received message IDs, the message MUST be dropped.
Message forwarding MUST always be done in a hop-by-hop manner. This
means that each hop is responsible for delivering the message to the
next hop on the path to the destination. For each multicasted
message (GETCERTIFICATE, CERTIFICATE, GETKEY, KEY, MESSAGE, OBSCURE)
the peer can be sure that the message reached the next hop if it
received an ACK for the respective message. If a peer detects a
route failure (if it receives no ACK from the next hop for that
message), it MUST find an alternative way to deliver the packet
towards the destination. For this, it e.g. may immediately try to
find an alternative route to the destination or cache the message for
some time and try it later again. The concrete stragegy is an
implementation issue. If a message's TTL expires while the message
is cached, the node MUST send a NACK message to the sender of the
message and drop the original message.
2.5. Security
In order to support signed messages, closed channel communication and
anonymous communication, a user MUST have an RSA keypair, the
keylength being 1024 bit. In order to be able to prove his/her
identity each user must have an X.509 certificate for his/her public
key.
Signing of the messages SHOULD always be done with the exception of
anonymous messages. The mandatory algorithms are MD5 with RSA. The
concatenation of all text sub-nodes of the message starting at the
message type node, but excluding any receiver elements, form the
input to the signing process (see the XML Schema definition in
Appendix A for further details).
All messages of a closed channel MUST be encrypted using symmetric
cryptography. Therefore, the creator of a closed channel generates a
shared secret key which is encrypted and sent to all participants
(upon request and optionally in advance) using the respective public
key of each participant. The RSA encryption MUST use the Electronic
Code Book (ECB) mode with the padding scheme PKCS1 (v1.5). The
mandatory symmetric algorithm is standard 64 (56) bit DES in Cipher
Block Chaining (CBC) mode with the padding scheme PKCS5 enabled.
Further symmetric algorithms may be added in the future. Note: Only
the content of the text element in a MESSAGE message is encrypted.
If the message contains one or more attachments, the content of the
filename, applicationtype, and data elements is encrypted
individually. (see the XML Schema definition in Appendix A for
further details).
Strauss, et al. Expires October 3, 2007 [Page 8]
Internet-Draft P2P Chat Protocol April 2007
2.6. Anonymous Communication
In order to allow anonymous posting of messages, an anonymous channel
is supported. This channel is omnipresent, i.e., does not need
channel announcements, does not die etc. Each active user is
automatically a member of it. The channel name "Anonymous" is
reserved for the anonymous channel and MUST NOT be used for other
channels.
Anonymous communication consists of two phases: the path-obscuring
and the posting of the message.
In the beginning, the sender creates a list of at least 3 and up to 5
random active users, which help in obscuring the path and thus the
sender's identity. The MESSAGE message that the sender wants to post
MUST be encrypted with the public key of the last user in the list
(RSA in ECB mode with PKCS1 (v1.5) padding). This data forms the
content of the OBSCURE message that is destined at the last user.
This OBSCURE message is then again encrypted with the public key of
the last but one user in the list and forms the content of another
OBSCURE message, which is destined at that user. This scheme MUST be
repeated until the list is empty. The final OBSCURE message, is sent
to the first user in the list.
Upon reception of an OBSCURE message at its target node, the content
MUST be decrypted. If the decrypted message content is another
OBSCURE message it MUST be sent on to the receiver that is already
placed in the message. In case of the decrypted message being the
message to be posted, it MUST be flooded to the network.
In order to prevent message loss during the path-obscuring phase, the
original sender SHOULD resend the message if it has not been posted
to the anonymous channel after a timeout. In this case, the sender
SHOULD create a different list of active users and encrypt the
message according to the above defined rules.
Strauss, et al. Expires October 3, 2007 [Page 9]
Internet-Draft P2P Chat Protocol April 2007
3. The Protocol
This section describes the peer-to-peer chat protocol version 2.
3.1. Protocol Message Format
Each message represents a well-formed XML [XML] document. Each
message MUST be sent to its destination in an individual UDP datagram
[RFC768]. It is not allowed to put several messages in a single
datagram. The maximum message size is limited to 63000 bytes. Only
NACK messages are allowed to exceed this limit. Each message
(including NACKs) MUST fit into one UDP datagram. It is not be
possible to split up messages over several datagrams.
An XML Schema definition for messages is given in Appendix A.
3.2. Protocol Message Exchange
Every message is of a specific message type given by the one and only
direct child element of the root element of the message XML document.
All protocol messages are handled asynchronously, i.e., a node MUST
NOT block and wait for a certain reply message when a request message
was sent.
Each chat message contains two attributes used for routing purposes:
TTL and FLOOD. The TTL value of each message MUST be decremented on
each hop as well as for every full second a message is held on a node
before it is forwarded to the next hop. Note that the initial TTL
values are mandatory, since they may be used to derive routing
information. The FLOOD flag indicated whether a message MUST be
flooded through the network.
In addition, messages MAY contain a DELAY attribute that states the
cumulative queuing time in seconds at all intermediate nodes. This
value is incremented for every second a packet is queued on an
intermediate node for any reason. This value can be used to
determine messages with high delays.
3.3. Protocol Messages
This section describes all protocol message types. The named message
types are equal to the name of the one and only direct child element
of the corresponding "chat-message" root element. Note that message
types are just written all caps in this document for readability.
Strauss, et al. Expires October 3, 2007 [Page 10]
Internet-Draft P2P Chat Protocol April 2007
3.3.1. HELLO
The HELLO message MUST be sent periodically by each node. The
interval between two successive HELLO messages MUST be 2 seconds +/-
0.5 seconds. A peer SHOULD choose a new interval randomly between
1.5 and 2.5 seconds for each individual beacon in order to reduce the
collision probability. The HELLO message can be used to detect other
peers in the local neighborhood. If no further HELLO message is
received for three successive HELLO intervals, the remote node may be
moved out of the transmission range.
3.3.2. ACK
An ACK message MUST be sent in response to a GETCERTIFICATE,
CERTIFICATE, GETKEY, KEY, MESSAGE or OBSCURE message. The message
informs the sender or forwarder of a message that this message has
arrived at the next hop. It MUST include the message ID of the
received message.
3.3.3. NACK
A NACK message MUST be sent if the TTL of a message becomes zero on
the way to the destinations. It is used to inform the original
sender about the fact that its message has not received all
destinations. The actions that are taken by a node that receives a
NACK for one of its messages sent is an implementation issue. The
NACK message MUST only be sent to the original sender of the message.
Moreover, it MUST include the whole original message. In addition, a
NACK messages includes the user ID of its sender and a unique message
ID.
3.3.4. CHANNEL
A CHANNEL message for a specific channel is sent
o once when a local user creates a channel,
o when the node did not receive a CHANNEL message for the channel
for a certain time and as long as a local user is still subscribed
to that channel. This time SHOULD be a random value in the range
between 50 and 60 seconds.
o Furthermore, CHANNEL messages MIGHT be sent once for each known
channel to a newly connected peer node.
This ensures that channels keep alive and known (including the
subscribers) to all nodes. A CHANNEL message SHOULD be sent with
ttl="32". The TTL value MUST be lower than the minimal channel
Strauss, et al. Expires October 3, 2007 [Page 11]
Internet-Draft P2P Chat Protocol April 2007
announcement interval. The CHANNEL message is always flooded to the
whole network.
Each channel is identified by a channel name and a channel ID. The
name of a new channel MUST differ from the names of existing
channels. While the name is a descriptive identifier for a channel,
each channel also has a unique channel ID that MUST differ from other
known IDs and SHOULD be generated according to Section 1.1. If a
node recognizes two channels with the same names, they have to be
handled according to Section 2.3.
The CHANNEL message always contains the list of subscribed channel
members. Only these users are allowed to send messages to the
channel. Messages for a specific channel coming from other users
MUST be ignored. Nevertheless, a node MAY wait for the next channel
announcement before dropping the message. In case of a closed
channel only the users in the subscription list of the CHANNEL
message are allowed to retrieve the session key through a GETKEY/KEY
message pair. Users of a closed channel are allowed to add further
members to the list by sending a new CHANNEL message with the
extended list. CHANNEL messages of closed channels MUST be signed by
the sender to prevent non-members from adding themselves or other
users to the list.There is no way to reduce the members list of
closed channels, since it is obviously not possible to revoke a
shared secret.
Note that a public channel cannot later be turned into a closed
channel. There is no way to actively close or remove a channel. A
channel is "gone", when there are no more nodes that send regular
CHANNEL messages.
3.3.5. JOIN
A node sends a JOIN message
o once when a local user subscribes to a channel,
o when a local user is already subscribed to a channel for which a
CHANNEL message is received that does not (yet) list that local
user.
The JOIN message is always flooded to the whole network.
3.3.6. LEAVE
A node sends a LEAVE message
Strauss, et al. Expires October 3, 2007 [Page 12]
Internet-Draft P2P Chat Protocol April 2007
o once when a local user unsubscribes from a channel,
o when a local user is not subscribed to a channel for which a
CHANNEL message is received that does (still) list that local
user.
The LEAVE message is always flooded to the whole network.
3.3.7. GETCERTIFICATE
A node may request a certificate for a given user ID by sending a
GETCERTIFICATE message. This is usually caused by the wish to verify
the signature of a received message, when the according certificate
is not yet available at the local node. Note that the sender of the
GETCERTIFICATE (and the receiver of the response) is identified by a
user ID although certificates may be used to serve all users at the
local node.
3.3.8. CERTIFICATE
A node can send a certificate encapsulated in a CERTIFICATE message.
This MAY be done in advance (e.g., to all channel members before
sending a signed message to a channel) to avoid subsequent
GETCERTIFICATE/CERTIFICATE message traffic. Furthermore, a
CERTIFICATE message MUST be sent in response to a received
GETCERTIFICATE message for a local user. An intermediate node MAY
also send a CERTIFICATE message in response to a GETCERTIFICATE
message if it has the certificate of the requested user in its local
cache. In this case, it MUST NOT forward the GETCERTIFICATE message
along the route to the destination.
3.3.9. GETKEY
A node may request a channel key for a given closed channel by
sending a GETKEY message to the one member that sent and signed the
channel announcement. This MUST only be done if a previous CHANNEL
message has been received and the local user's ID is on the members
list of that channel.
If a GETKEY message is received and a KEY response (see below) can be
sent, the GETKEY message MUST be dropped and not forwarded to any
other receivers.
3.3.10. KEY
A node MUST send a channel key encapsulated in a KEY message in
response to a GETKEY message sent to the local user. The key MUST be
encrypted for that user. The sender MUST be sure that the receiver
Strauss, et al. Expires October 3, 2007 [Page 13]
Internet-Draft P2P Chat Protocol April 2007
is a member of the closed channel and the public key used for the key
encryption really belongs to the receiver. This is usually done
through a certificate verification process.
3.3.11. ROUTING
A node MUST send a ROUTING message on a regular basis to all its
neighboring peers. Each entry of the ROUTING message represents a
known user and signals the number of hops it takes to reach that
user, i.e., the receiver of the ROUTING message can subsequently
reach those users via that link with n+1 hops.
The interval to send ROUTING messages SHOULD be chosen randomly from
the interval [8,10] seconds. Additionally, the node MIGHT send
ROUTING messages upon changes to the local routing table, but it MUST
NOT send more than one message per second.
Note that a node MIGHT also "learn" additional routing information
based on other messages than ROUTING messages through the sender and
TTL values.
3.3.12. MESSAGE
The users' text messages within channels are distributed in MESSAGE
messages. With the exception of anonymous MESSAGE messages, the
initial sender of a MESSAGE message MUST put all members of the
channel into the receivers list. A MESSAGE message MAY contain one
or more attachments. The attached data MUST be Base64 encoded. An
attached file is described by a filename and the application MIME
type [RFC2045][RFC2046]. In case of a closed channel, the content of
messages MUST be sent encrypted with the channel key (which probably
must be retrieved through a GETKEY/KEY conversation first).
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.
A MESSAGE message MUST NOT exceed the packet size limit mentioned in
Section 3.1
A node that receives a MESSAGE message MUST forward the message on
each link (except the incoming link) on which it can reach at least
one of the receivers through the shortest path. All receivers for
which the link does not supply the shortest path are removed before
forwarding.
Strauss, et al. Expires October 3, 2007 [Page 14]
Internet-Draft P2P Chat Protocol April 2007
In case of the MESSAGE message being the final message of an
anonymization chain, its message ID MUST be inserted by the sender of
the message, and the anonymous originator MUST NOT have placed a
message ID in the message. Furthermore, the message MUST be destined
at the channel 'Anonymous'.
3.3.13. OBSCURE
An OBSCURE message is an anonymous message in the path- obscuring
phase. The content MUST contain another OBSCURE message or a MESSAGE
message which MUST be encrypted with the receiver's public key.
A node that receives an OBSCURE message MUST decrypt the content with
its private key and MUST send on the resulting message in a new chat
message.
The message ID of an OBSCURE message MUST be inserted by its
immediate sender, i.e., not the initial creator of the OBSCURE
message chain.
An OBSCURE message MUST NOT exceed the packet size limit mentioned in
Section 3.1
Strauss, et al. Expires October 3, 2007 [Page 15]
Internet-Draft P2P Chat Protocol April 2007
4. Security Considerations
This document defines an application protocol to carry potentially
private or authentic information. The protocol addresses these needs
through the application of strong cryptographic digest and encryption
algorithms. X.509 certificates are used to verify identities of end
users. This document requires implementations to support a minimal
common set of cryptographic algorithms so that from the
specifications point of view secure communication can be guaranteed.
However, anonymous communication makes assumptions that cannot be
always guaranteed, i.e. an attacker is not able to trace the complete
path an anonymous message takes before being posted to the anonymous
channel.
At the current status the protocol takes no measures to protect
against DoS attacks by peers.
Strauss, et al. Expires October 3, 2007 [Page 16]
Internet-Draft P2P Chat Protocol April 2007
5. Acknowledgements
The protocol described in this memo is the output of a practical
course on distributed systems that has been conducted during two
terms at Technische Universitaet Braunschweig in April - July, 2003
and in the same summer term in 2004. A first step of the work
presented here has been developed by the approx. 48 participating
students of the first course in 2003 during a two-weeks design phase
and a subsequent protocol design colloquium. Then the second course
in 2004 improved routing concepts significantly and added anonymous
communication in a similar design and colloquium way. In 2007 the
protocol has been extended to support mobility issues in Wireless Ad
Hoc Networks. Thus, the transport protocol has be switched from TCP
to UDP. In addition, several changes regarding neighbour discovery,
disruption tolerance, and node mobility were introduced. The
extended protocol is the basis for a practical course on software
engeneering at Technische Universitaet Braunschweig in April - July
2007
The authors of this memo are basically the editors who have put the
design decisions together in a common specification document along
with some refinements and mobility support. Hence, the authors'
thanks go to all the ambitious students of the summer 2003 and summer
2004 PVS courses.
Strauss, et al. Expires October 3, 2007 [Page 17]
Internet-Draft P2P Chat Protocol April 2007
Appendix A. XML Schema Definition for Messages
<?xml version="1.0"?>
<!-- $Id$
-
-->
<xsd:schema
targetNamespace="http://www.ibr.cs.tu-bs.de/chat-message"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.ibr.cs.tu-bs.de/chat-message"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en">
<xsd:annotation>
<xsd:documentation>
This XML Schema defines the p2p-chat protocol messages.
</xsd:documentation>
</xsd:annotation>
<!--
- Types
-->
<xsd:simpleType name="UserIDType">
<xsd:annotation>
<xsd:documentation>
Elements of this type represent a globally unique user
identification. It has to contain a user name part followed by
an @ character and a domain part. It is highly recommended to
use the users valid Internet email address. Note that it has
to be treated case-insensitive.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9_\.\-]{1,127}@[a-zA-
Z0-9_\.\-]{1,128}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="MessageIDType">
<xsd:annotation>
<xsd:documentation>
Elements of this type are used to form a unique identification
for messages per user. The pair of a UserID and a MessageID
builds a globally unique message identification. How the
Strauss, et al. Expires October 3, 2007 [Page 18]
Internet-Draft P2P Chat Protocol April 2007
MessageID is actually built is an implementation issue. It
might be a persistent counter incremented with each message
generation, or it might be based on a timestamp, for example.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9@_\.\-]{1,256}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ChannelIDType">
<xsd:annotation>
<xsd:documentation>
Elements of this type are used to form a unique identification
for channels. The pair of a channel name and a channelID
builds a globally unique channel identification. How the
channelID is actually built is an implementation issue. The
channelID MUST differ from other known IDs. Is consists of two
parts sperarated by an "@". The first part SHOULD be
generated randomly on the basis of UUIDs. The second part is
the name of the local host.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9_\.\-]{1,127}@[a-zA-
Z0-9_\.\-]{1,128}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TTLType">
<xsd:annotation>
<xsd:documentation>
An integer time-to-live value. Note that the value range is
restricted.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:int">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="360"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ChannelNameType">
<xsd:annotation>
<xsd:documentation>
The name of a channel. Note that it has to be treated
case-insensitive. The name "Anonymous" is reserved
Strauss, et al. Expires October 3, 2007 [Page 19]
Internet-Draft P2P Chat Protocol April 2007
for the
anonymous channel and MUST NOT be used for other channels.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9_\.\-]{1,16}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="DestinationType">
<xsd:annotation>
<xsd:documentation>
A destination is part of a routing message. It signals
the number of hops to reach a user via the link on which
the routing message is sent.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="user" type=
"UserIDType"/>
<xsd:element name="hops" type=
"xsd:unsignedInt"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CertificateType">
<xsd:annotation>
<xsd:documentation>
A certificate consists of the user ID to which the certificate
belongs and the certificate itself encoded in Base64.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="user" type=
"UserIDType"/>
<xsd:element name="data" type=
"xsd:base64Binary"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AttachmentType">
<xsd:annotation>
<xsd:documentation>
A message attachment. The applicationtype states the MIME Type
of the attached file.
Strauss, et al. Expires October 3, 2007 [Page 20]
Internet-Draft P2P Chat Protocol April 2007
The application data MUST always be Base64 encoded.
If the iv attribute is present,
it is a message of a closed channel and uses the
initialization
vector given by the iv attribute. The content of all elements
MUST be de-/encrypted individually.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="filename" type=
"xsd:string"/>
<xsd:element name="applicationtype" type=
"xsd:string"/>
<xsd:element name="data" type=
"xsd:base64Binary"/>
</xsd:sequence>
<xsd:attribute name="iv" type=
"xsd:base64Binary"/>
</xsd:complexType>
<xsd:simpleType name="CipherType">
<xsd:annotation>
<xsd:documentation>
A label to identify a symmetric cipher algorithm. So far,
just one (reasonable) cipher is defined, but others may be
added in future revision of the protocol.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="NONE">
<xsd:annotation>
<xsd:documentation>
No encryption.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="DES-CBC">
<xsd:annotation>
<xsd:documentation>
64(56) bit DES in Cipher Block Chaining mode with PKCS #5
padding.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
Strauss, et al. Expires October 3, 2007 [Page 21]
Internet-Draft P2P Chat Protocol April 2007
<xsd:simpleType name="SignType">
<xsd:annotation>
<xsd:documentation>
A label to identify a message digest algorithm. So far, just
one algorithm is defined, but others may be added in future
revision of the protocol.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="MD5">
<xsd:annotation>
<xsd:documentation>
MD5 digest (encrypted with the senders private key).
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SignatureType">
<xsd:annotation>
<xsd:documentation>
A Base64 encoded signature. It is calculated for the
concatenated UTF-8 encoded values (without attributes) of all
child elements of the chat-message element in depth-first
order.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:base64Binary"/>
</xsd:simpleType>
<!--
- Root Element and Message Types
-->
<xsd:element name="chat-message" type=
"ChatMessage"/>
<xsd:complexType name="ChatMessage">
<xsd:annotation>
<xsd:documentation>
This element represents a p2p-chat protocol
message.
</xsd:documentation>
</xsd:annotation>
Strauss, et al. Expires October 3, 2007 [Page 22]
Internet-Draft P2P Chat Protocol April 2007
<xsd:sequence>
<xsd:choice>
<xsd:element name="hello" type=
"HelloMessage"/>
<xsd:element name="ack" type=
"AckMessage"/>
<xsd:element name="nack" type=
"NackMessage"/>
<xsd:element name="channel" type=
"ChannelMessage"/>
<xsd:element name="join" type=
"JoinMessage"/>
<xsd:element name="leave" type=
"LeaveMessage"/>
<xsd:element name="getcertificate"
type="GetCertificateMessage"/>
<xsd:element name="certificate"
type="CertificateMessage"/>
<xsd:element name="getkey" type=
"GetKeyMessage"/>
<xsd:element name="key" type=
"KeyMessage"/>
<xsd:element name="routing" type=
"RoutingMessage"/>
<xsd:element name="message" type=
"MessageMessage"/>
<xsd:element name="obscure" type=
"ObscureMessage"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="ttl" type=
"TTLType"
default="1"/>
<xsd:attribute name="delay" type=
"xsd:int"
default="0"/>
<xsd:attribute name="flood" type=
"xsd:boolean"
default="false"/>
<xsd:attribute name="signtype" type=
"SignType"/>
<xsd:attribute name="signature" type=
"SignatureType"/>
</xsd:complexType>
<xsd:complexType name="HelloMessage">
<xsd:annotation>
<xsd:documentation>
Strauss, et al. Expires October 3, 2007 [Page 23]
Internet-Draft P2P Chat Protocol April 2007
The "hello" message is the first message sent by
each peer of
a newly established connection. The peer may send an informal
greeting text. A HELLO message MAY contain more than one
sender
if a node serves more than one user.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"
minOccurs="1" maxOccurs="unbounded"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="version" type=
"xsd:int"/>
<xsd:element name="greeting" type=
"xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AckMessage">
<xsd:annotation>
<xsd:documentation>
The "ack" message is sent by a peer that receives a
multicasted
message from another peer in order to inform the sender that
this message reached the next hop. It always includes the ID
of the received message.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="NackMessage">
<xsd:annotation>
<xsd:documentation>
The "Nack" message is sent by a peer that receives a
multicasted
message from another peer and is not able to forward it
towards its destination. The "Nack" message is
always sent to
the original source of that message and informs the sender
Strauss, et al. Expires October 3, 2007 [Page 24]
Internet-Draft P2P Chat Protocol April 2007
that its message has not received its destination. The
original message has to be attached to the "Nack".
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="message" type=
"ChatMessage"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ChannelMessage">
<xsd:annotation>
<xsd:documentation>
The "channel" message announces an active channel.
The
"closed" flag denotes whether it is a closed
channel.
Each known subscriber is listed in a "member" child
element.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="channel" type=
"ChannelNameType"/>
<xsd:element name="channelid" type=
"ChannelIDType"/>
<xsd:element name="description" type=
"xsd:string"/>
<xsd:element name="member" type=
"UserIDType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="closed" type=
"xsd:boolean"
default="false"/>
</xsd:complexType>
<xsd:complexType name="JoinMessage">
<xsd:annotation>
Strauss, et al. Expires October 3, 2007 [Page 25]
Internet-Draft P2P Chat Protocol April 2007
<xsd:documentation>
The "join" message signal the subscription of a user
to
a non-closed channel.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="channel" type=
"ChannelNameType"/>
<xsd:element name="channelid" type=
"ChannelIDType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LeaveMessage">
<xsd:annotation>
<xsd:documentation>
The "leave" message signal the unsubscription of a
user from
a non-closed channel.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="channel" type=
"ChannelNameType"/>
<xsd:element name="channelid" type=
"ChannelIDType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetCertificateMessage">
<xsd:annotation>
<xsd:documentation>
A node may send a "getcertificate" message to
request a
certificate for a given user ID.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
Strauss, et al. Expires October 3, 2007 [Page 26]
Internet-Draft P2P Chat Protocol April 2007
"UserIDType"/>
<xsd:element name="receiver" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CertificateMessage">
<xsd:annotation>
<xsd:documentation>
A node can send a certificate encapsulated in
a "certificate" message. It's not only the
owner of
the certificate who can send such a message.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="receiver" type=
"UserIDType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="certificate" type=
"CertificateType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetKeyMessage">
<xsd:annotation>
<xsd:documentation>
A node may request a channel key for a given closed channel
through a "getkey" message.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="receiver" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="channel" type=
"ChannelNameType"/>
<xsd:element name="channelid" type=
"ChannelIDType"/>
Strauss, et al. Expires October 3, 2007 [Page 27]
Internet-Draft P2P Chat Protocol April 2007
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="KeyMessage">
<xsd:annotation>
<xsd:documentation>
A node can send a channel key encapsulated in a
"key"
message. The actual data part of the key has to be encrypted
with the according receiver's public key. It is the duty
of
the sender of a "key" message to ensure that the
public key
really belongs to the receiver and that the receiver is
really a member of the channel.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"/>
<xsd:element name="receiver" type=
"UserIDType"/>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="channel" type=
"ChannelNameType"/>
<xsd:element name="channelid" type=
"ChannelIDType"/>
<xsd:element name="cipher" type=
"CipherType"/>
<xsd:element name="key" type=
"xsd:base64Binary"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RoutingMessage">
<xsd:annotation>
<xsd:documentation>
Routing messages are exchanged on links to form a converging
knowledge on the network topology on every node.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="messageid" type=
"MessageIDType"/>
<xsd:element name="destination" type=
"DestinationType"
minOccurs="0" maxOccurs="unbounded"/>
Strauss, et al. Expires October 3, 2007 [Page 28]
Internet-Draft P2P Chat Protocol April 2007
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MessageMessage">
<xsd:annotation>
<xsd:documentation>
The "message" message carries the actual content of
the chat
message in its text element. If the iv attribute is present
it is a message of a closed channel and uses the
initialization
vector given by the iv attribute.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type=
"UserIDType"
minOccurs="0"/>
<xsd:element name="receiver" type=
"UserIDType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="messageid" type=
"MessageIDType"
minOccurs="0"/>
<xsd:element name="timestamp" type=
"xsd:dateTime"/>
<xsd:element name="channel" type=
"ChannelNameType"
minOccurs="0"/>
<xsd:element name="channelid" type=
"ChannelIDType"
minOccurs="0"/>
<xsd:element name="text">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="iv" type=
"xsd:base64Binary"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="attachment" type=
"AttachmentType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
Strauss, et al. Expires October 3, 2007 [Page 29]
Internet-Draft P2P Chat Protocol April 2007
<xsd:complexType name="ObscureMessage">
<xsd:annotation>
<xsd:documentation>
The "obscure" is created by a user who intends to
emit a
"message" message but remain anonymous as the sender
of the
message. The "text" payload is in turn an
"obscure" message
or a "message" message after decryption.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="receiver" type=
"UserIDType" />
<xsd:element name="messageid" type=
"MessageIDType"
minOccurs="0"/>
<xsd:element name="text" type=
"xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Strauss, et al. Expires October 3, 2007 [Page 30]
Internet-Draft P2P Chat Protocol April 2007
6. Normative References
[ITUX667] International Telecommunication Union (ITU-T),
"Information technology - Open Systems Interconnection -
Procedures for the operation of OSI Registration
Authorities: Generation and registration of Universally
Unique Identifiers (UUIDs) and their use as ASN.1 Object
Identifier components", Rec X.667, September 2004.
[RFC768] Postel, J., "User Datagram Protocol", RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
W3C Recommendation 1, October 2000.
Strauss, et al. Expires October 3, 2007 [Page 31]
Internet-Draft P2P Chat Protocol April 2007
Authors' Addresses
Frank Strauss
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391-3268
Email: strauss@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Stefan Ransom
Universitaet zu Luebeck
Ratzeburger Allee 160
23538 Luebeck
Germany
Phone: +49 451 500-5385
Email: ransom@itm.uni-luebeck.de
URI: http://www.itm.uni-luebeck.de/
Sven Lahde
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391-3264
Email: lahde@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Oliver Wellnitz
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391-3266
Email: wellnitz@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Strauss, et al. Expires October 3, 2007 [Page 32]
Internet-Draft P2P Chat Protocol April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Strauss, et al. Expires October 3, 2007 [Page 33]