SIMPLE WG C. Jennings
Internet-Draft R. Mahy
Expires: January 14, 2005 Cisco Systems, Inc.
July 16, 2004
Relay Extensions for Message Sessions Relay Protocol (MSRP)
draft-ietf-simple-msrp-relays-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 January 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The SIMPLE Working Group uses two separate models for conveying
instant messages. Pager-mode messages stand alone, whereas
Session-mode messages are setup as part of a session using the SIP
protocol. MSRP (Message Sessions Relay Protocol) is a protocol for
near-real-time, peer-to-peer exchange of binary content without
intermediaries, which is designed to be signaled using a separate
rendezvous protocol such as SIP. This document introduces the notion
of message relay intermediaries to MSRP and describes the extensions
necessary to use them.
Jennings & Mahy Expires January 14, 2005 [Page 1]
Internet-Draft MSRP Relays July 2004
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction and Requirements . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of New Protocol Elements . . . . . . . . . . . . . . 9
4.1 The AUTH Method . . . . . . . . . . . . . . . . . . . . . 9
4.2 The Use-Path header . . . . . . . . . . . . . . . . . . . 10
4.3 Authentication headers . . . . . . . . . . . . . . . . . . 10
4.4 Time-related headers . . . . . . . . . . . . . . . . . . . 10
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Client behavior . . . . . . . . . . . . . . . . . . . . . 11
5.1.1 Connecting to relays acting on your behalf . . . . . . 11
5.1.2 Sending requests . . . . . . . . . . . . . . . . . . . 13
5.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 14
5.1.4 Managing Connections . . . . . . . . . . . . . . . . . 14
5.2 Relay behavior . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 Handling Incoming Connections . . . . . . . . . . . . 14
5.2.2 Generic request behavior . . . . . . . . . . . . . . . 14
5.2.3 Receiving AUTH requests . . . . . . . . . . . . . . . 14
5.2.4 Forwarding SEND requests . . . . . . . . . . . . . . . 16
5.2.5 Forwarding non-SEND requests . . . . . . . . . . . . . 17
5.2.6 Forwarding Responses . . . . . . . . . . . . . . . . . 17
5.2.7 Managing Connections . . . . . . . . . . . . . . . . . 18
5.2.8 Forwarding unknown requests . . . . . . . . . . . . . 18
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Finding MSRP Servers . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1 Using HTTP Authentication . . . . . . . . . . . . . . . . 20
8.2 Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 21
8.4 Security Mechanism . . . . . . . . . . . . . . . . . . . . 22
8.5 Preventing Spam and Denial of Service Attacks . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Example SDP with multiple hops . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
12.2 Informative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 27
Jennings & Mahy Expires January 14, 2005 [Page 2]
Internet-Draft MSRP Relays July 2004
1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Below we list several definitions important to MSRP:
MSRP node: a host that implements the MSRP protocols as a Client or a
Relay
MSRP Client: an MSRP role which is the initial sender or final target
of messages and delivery status.
MSRP Relay: an MSRP role which forwards messages and delivery status
and may provide policy enforcement. Relays can fragment and
reassemble portions of messages.
Message: arbitrary MIME content which one client wishes to send to
another. For the purposes of this specification, a complete MIME
body as opposed to a portion of a complete message.
chunk: a portion of a complete message delivered in a SEND request.
end-to-end: delivery of data from the initiating client to the final
target client
hop: delivery of data between one MSRP node and an adjacent node.
2. Introduction and Requirements
The IETF SIMPLE Working Group has identified a number of scenarios
where using a separate protocol for bulk messaging is desirable. In
particular, the SIMPLE WG will use this facility to handle a sequence
of messages as a session of media initiated using SIP [2], just like
any other media type. (The benefits of the session-mode approach are
further discussed in [19].) The SIMPLE Working Group has also
developed MSRP (the Message Sessions Relay Protocol) to convey
sessions of messages directly between two end systems with no
intermediaries. With MSRP, messages can be arbitrarily large and all
traffic is sent over reliable, congestion-safe transports.
This document describes extensions to the core MSRP protocol to
introduce intermediaries called Relays. With these extensions MSRP
clients can communicate directly, or through an arbitrary number of
relays. Each client is responsible for identifying any relays acting
on its behalf and providing appropriate credentials. Clients which
can receive new TCP connections directly do not have to implement any
new functionality to work with these relays.
The Goals of the MSRP Relay extensions are listed below:
o convey arbitrary binary MIME data without modification or transfer
encoding
o continue to support client to client operation (no relay servers
required)
Jennings & Mahy Expires January 14, 2005 [Page 3]
Internet-Draft MSRP Relays July 2004
o operate through an arbitrary number of relays for policy
enforcement
o allow each client to control which relays are traversed on its
behalf
o prevent unsolicited messages (spam), "open relays", and denial of
service amplification
o allow relays to use one or a small number of TCP or TLS [3]
connections to carry messages for multiple sessions, recipients,
and senders
o allow large messages to be sent over a slow connection without
causing head-of-line blocking problems
o allow transmission of a large message to be interrupted and
resumed in place when network connectivity is lost and later
reestablished
o offer notification of message failure at any intermediary
o provide notification of message storage (desirable)
o allow relays to delete state after a short amount of time
3. Protocol Overview
With the introduction of this extension, MSRP has the concept of both
clients and relays. Clients send messages to relays and/or other
clients. Relays forward messages and message delivery status to
clients and other relays. Clients which can open TCP connections to
each other without intervening policy restrictions, can communicate
directly with each other. Clients who are behind a firewall or who
need to use an intermediary for policy reasons can use the services
of a relay. Each client is responsible for enlisting the assistance
of one or more relays for its half of the communication.
Clients which use a relay operate by first opening a TLS connection
with a relay, authenticating, and retreiving an msrps: URI (from the
relay) that the client can provide to its peers to receive messages
later. When a client uses a relay, it first opens a TLS connection
to its first relay and authenticates using an AUTH request which can
contain HTTP Digest [4] Authentication credentials. In a successful
AUTH response, the relay provides an msrps: URI associated with the
path back to the client that the client can give to other clients for
end-to-end message delivery.
When clients wish to send a short message, they issue a SEND request
with the entire contents of the message. If any relays are required,
they are included in the To-Path header. The leftmost URI in the
To-Path header is the next hop to deliver a request or response. The
rightmost URI in the To-Path header is the final target. (Note that
MSRP does not permit line folding. A "\" in the examples shows a
line continuation due to limitations in line length of this document.
Neither the backslash, nor the extra CRLF are included in the actual
Jennings & Mahy Expires January 14, 2005 [Page 4]
Internet-Draft MSRP Relays July 2004
request or response.)
MSRP 6aef SEND
To-Path: msrps:example.org:9000/kjfjan \
msrps:example.net:9000/aeiug \
msrps:bob.example.net:8145/foo
From-Path: msrps:alice.example.com:7965/bar
Report-Success: yes
Content-Type: text/plain
Hi Bob, I'm about to send you LoTR.mpeg
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps:alice.example.com:7965/bar
From-Path: msrps:example.org:9000/kjfjan
-------6aef$
MSRP juh76 SEND
To-Path: msrps:example.net:9000/aeiug \
msrps:bob.example.net:8145/foo
From-Path: msrps:example.org:9000/kjfjan \
msrps:alice.example.com:7965/bar
Report-Success: yes
Content-Type: text/plain
Hi Bob, I'm about to send you LoTR.mpeg
-------juh76$
MSRP juh76 200 OK
To-Path: msrps:example.org:9000/kjfjan
From-Path: msrps:example.net:9000/aeiug
-------juh76$
MSRP xght6 SEND
To-Path: msrps:bob.example.net:8145/foo
From-Path: msrps:example.net:9000/aeiug \
msrps:example.org:9000/kjfjan \
msrps:alice.example.com:7965/bar
Report-Success: yes
Content-Type: text/plain
Hi Bob, I'm about to send you LoTR.mpeg
-------xght6$
MSRP xght6 200 OK
To-Path: msrps:example.net:9000/aeiug
Jennings & Mahy Expires January 14, 2005 [Page 5]
Internet-Draft MSRP Relays July 2004
From-Path: msrps:bob.example.net:8145/foo
MSRP yh67 REPORT
To-Path: msrps:example.net:9000/aeiug \
msrps:example.org:9000/kjfjan \
msrps:alice.example.com:7965/bar
From-Path: msrps:bob.example.net:8145/foo
Status: 000 200 OK
Report-Failure: no
-------yh67$
MSRP yh67 REPORT
To-Path: msrps:example.org:9000/kjfjan \
msrps:alice.example.com:7965/bar
From-Path: msrps:example.net:9000/aeiug \
msrps:bob.example.net:8145/foo
From-Path: msrps:bob.example.net:8145/foo
Status: 000 200 OK
Report-Failure: no
-------yh67$
MSRP yh67 REPORT
To-Path: msrps:alice.example.com:7965/bar
From-Path: msrps:example.org:9000/kjfjan \
msrps:example.net:9000/aeiug \
msrps:bob.example.net:8145/foo
From-Path: msrps:bob.example.net:8145/foo
Status: 000 200 OK
Report-Failure: no
-------yh67$
Jennings & Mahy Expires January 14, 2005 [Page 6]
Internet-Draft MSRP Relays July 2004
Typical flow involving two relays
Alice a.example.org b.example.net Bob
| | | |
|::::::::::::::::::::>| connection opened |<::::::::::::::::::::|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 401 Auth---------| |--- 401 Auth-------->|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 200 OK-----------| |--- 200 OK---------->|
| | | |
.... time passes ....
| | | |
|--- SEND ----------->| | |
|<-- 200 OK ----------|:::::::::::::::::::>| (slow link) |
| |--- SEND ---------->| |
| |<-- 200 OK ---------|--- SEND ----------->|
| | | ....>|
| | | ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT ----------|
| |<-- REPORT ---------| |
|<-- REPORT ----------| | |
| | | |
SEND requests are sent hop-by-hop. (Each relay that receives a SEND
request acknowledges receipt of the request before forwarding the
content in other SEND requests.) All other requests are sent
end-to-end.
With the introduction of relays, the subtle semantics of the To-Path
and From-Path header becomes more relevant. The To-Path in both
requests and responses is the list of URIs that need to be visited in
order to reach the final target of the request. The From-Path is the
list of URIs that indicate how to get back to the original sender of
the request or response . This differs from the To and From headers
in SIP, which do not "swap" from request to response. (Note that
sometimes a request is sent to or from an intermediary directly.)
When a relay forwards a request, it removes its address from the
To-Path header and inserts it at as the first URI in the From-Path
header. For example if the path from Alice to Bob is through relays
A and B, when B receives the request it contains path headers that
look like this:
To-Path: msrps:B msrps:Bob
From-Path: msrps:A msrps:Alice
after forwarding the request, the path headers look like this:
Jennings & Mahy Expires January 14, 2005 [Page 7]
Internet-Draft MSRP Relays July 2004
To-Path: msrps:Bob
From-Path: msrps:B msrps:A msrps:Alice
When the Report-Failure header is set appropriately, MSRP Nodes
respond to SEND requests by taking the last (rightmost) URI in the
From-Path and placing that in a To-Path header in the response, and
placing their URI in the From-Path of the response. Likwise, when
the Report-Failure header is set appropriately, MSRP Nodes respond to
all other requests addressed to them by swapping the To-Path and
From-Path headers and reversing the order of the resulting To-Path
header.
When sending large content the client may split up a messsage into
smaller pieces; each SEND request might contain only a portion of the
complete message. For example, when Alice sends Bob a 4GB file
called "LoTR.mpeg", she sends several SEND requests each with a
portion of the complete message. Relays can repack message fragments
en-route. As individual parts of the complete message arrive at the
final destination client, the receiving client can optionally send
REPORT requests indicating delivery status.
MSRP nodes can send individual portions of a complete message in
multiple SEND requests. As relays receive chunks they can reassemble
or re-fragment them as long as they resend the resulting chunks in
order. (Receivers still need to be prepared to receive out-of-order
chunks however). If the sender set the Report-Success header to yes,
once a chunk or complete message arrives at the destination client,
the destination sends a REPORT request indicating that a chunk
arrived end-to-end. This request travels back along the reverse path
of the SEND request. Unlike the SEND request which is acknowledged
along every hop, REPORT responses are never acknowledged.
Jennings & Mahy Expires January 14, 2005 [Page 8]
Internet-Draft MSRP Relays July 2004
Flow involving re-chunking through two relays
Alice a.example.org b.example.net Bob
| | | |
| | | |
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 401 Auth---------| |--- 401 Auth-------->|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 200 OK-----------| |--- 200 OK---------->|
| | | |
.... time passes ....
| | | |
|--- SEND 0-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 0-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 0-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 0-3 ------|
| |<-- REPORT 0-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 0-3 ------| | ...>|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
Relays only keep transaction state for a short period of time for
each chunk. Delivery over each hop should take no more than 32
seconds after the last byte of data is sent. Clients applications
define their own implementation-dependent timers for end-to-end
message delivery.
For client to client communication, the sender of a message typically
opens a new TCP connection (with or without TLS) if one is needed.
Relays reuse existing connections first, but can open new connections
(typically to another relay) to deliver requests such as SEND or
REPORT. Responses can only be sent over existing connections.
4. Overview of New Protocol Elements
4.1 The AUTH Method
AUTH requests are used by clients with ephemeral addresses to create
a handle they can use to receive incoming requests. AUTH requests
Jennings & Mahy Expires January 14, 2005 [Page 9]
Internet-Draft MSRP Relays July 2004
can also contain credentials used to authenticate a client, and
authorization policy used to block Denial of Service attacks. AUTH
requests are discussed in more detail in a later section.
In response to an AUTH request, a successful response contains a
Use-Path header with a list of URIs that the Client can give to its
peers to route responses back to the Client.
4.2 The Use-Path header
The Use-Path header is a list of URIs provided by an MSRP Relay in
response to a successful AUTH request. This list of URIs can be used
by the MSRP Client that sent the AUTH request to receive MSRP
requests, and to advertise this list of URIs, for example in a
session description.
4.3 Authentication headers
The Authentication-Info header provides optional information for HTTP
Digest authentication. This header MAY be included in the response
to an AUTH request. Semantics of the header are described in RFC
2617
The Authorization header contains authentication credentials for HTTP
Digest authentication in an AUTH request. Section [x.y] . Note that
the parameters of this header are separated by commas instead of
semicolons. The presence of commas in this header does not imply
that there is more than one header field value for this header field
(only one header field value is allowed). Semantics of the header
are described in RFC 2617. This header MUST NOT appear in any parcel
other than an AUTH request.
The WWW-Authenticate header contains an HTTP Digest challenge carried
in a 401 Response.
NOTE - only auth, not auth-int is needed because TLS provides
integrity
4.4 Time-related headers
The Expires header in a provides a relative time after which the
action implied by the method of the request is no longer of interest.
In a request, the Expires header indicates how long the sender would
like the request to remain valid. In a response, the Expires header
indicates how long the responder considers this information relevant.
Specifically an Expires header in an AUTH request indicates how long
the provided URIs will be valid.
Jennings & Mahy Expires January 14, 2005 [Page 10]
Internet-Draft MSRP Relays July 2004
The Min-Expires header contains the minimum duration a server will
permit in an Expires header. It is sent only in 423 "Interval
Out-of-Bounds" responses. Likewise the Max-Expires header contains
the maximum duration a server will permit in an Expires header.
423 Interval Out-of-bounds. Max-Expires header
5. Procedures
5.1 Client behavior
5.1.1 Connecting to relays acting on your behalf
Clients which want to use the services of a relay or list of relays,
need to send an AUTH request to each relay which will act on their
behalf. (For example, some organizations could deploy an "intra-org"
relay and an "extra-org" relay.)
Clients can be configured (typically through discovery or manual
provisioning) with a list of relays they need to use. They MUST be
able to form a connection to each relay and send an AUTH command to
get a URI that can be used in route headers. The client can
authenticate its first relay by looking at the relay's TLS
certificate. Each relay MUST authenticate the client using digest
authentication.
The relay will return a URI, or list of URIs, in the Use-Path header
of the response. These URIs are used by the client in the path
attribute that is sent in the SDP to setup the session. The same URI
can be used for multiple sessions to send to the client.
When sending an AUTH request, the client MAY add an Expires header to
request a MSRP URI that is valid for no longer that the provided
interval. If an AUTH request returns a 401 Unauthorized request, the
client SHOULD fetch the Digest challenge from the WWW-Authenticate
header in the response and retry the AUTH request, including an
Authorization header with the Digest response. Unlike in HTTP and
SIP, Digest authentication in MSRP is only permitted for AUTH
requests.
When a client wishes to use more than one relay, they must AUTH to
each relay they wish to use. Consider a client A, that whishes
messages to flow from A to the first relays, R1, then on to a second
relays, R2. This client with do a normal AUTH with R1. It will then
do an AUTH transaction with R2 that is routed through R1. The client
will form this AUTH messages by setting the To-Path to msrps:R1
msrps:R2. R1 will forward this (just like a REPORT request) on to
R2.
Jennings & Mahy Expires January 14, 2005 [Page 11]
Internet-Draft MSRP Relays July 2004
(Alice opens a TLS connection to intra.example.com)
MSRP 676sd AUTH
To-Path: msrps:alice@intra.example.com
From-Path: msrps:alice.example.com:9892/98cjs
-------676sd$
MSRP 676sd 401 Authenticate
To-Path: msrps:alice.example.com:9892/98cjs
From-Path: msrps:alice@intra.example.com
WWW-Authenticate:
-------676sd$
MSRP 49fh AUTH
To-Path: msrps:alice@intra.example.com
From-Path: msrps:alice.example.com:9892/98cjs
Authorization:
-------49fh$
MSRP 49fh 200 OK
To-Path: msrps:alice.example.com:9892/98cjs
From-Path: msrps:alice@intra.example.com
Use-Path: msrps:intra.example.com:9000/jui787s2f
-------49fh$
(Alice now sends an AUTH request to her "external" relay
through her "internal" relay, using the URI she just obtained)
MSRP quiyd2 AUTH
To-Path: msrps:intra.example.com:9000/jui787s2f \
msrps:extra.example.com
From-Path: msrps:alice.example.com:9892/98cjs
-------quiyd2$
MSRP quiyd2 AUTH
To-Path: msrps:extra.example.com
From-Path: msrps:intra.example.com:9000/jui787s2f \
msrps:alice.example.com:9892/98cjs
-------quiyd2$
MSRP quiyd2 401 Authenticate
To-Path: msrps:intra.example.com:9000/jui787s2f \
msrps:alice.example.com:9892/98cjs
From-Path: msrps:extra.example.com
WWW-Authenticate:
-------quiyd2$
MSRP quiyd2 401 Authenticate
Jennings & Mahy Expires January 14, 2005 [Page 12]
Internet-Draft MSRP Relays July 2004
To-Path: msrps:intra.example.com:9000/jui787s2f
From-Path: msrps:alice.example.com:9892/98cjs \
msrps:extra.example.com
WWW-Authenticate:
-------quiyd2$
MSRP mnbvw AUTH
To-Path: msrps:intra.example.com:9000/jui787s2f \
msrps:extra.example.com
From-Path: msrps:alice.example.com:9892/98cjs
-------mnbvw$
MSRP mnbvw AUTH
To-Path: msrps:extra.example.com
From-Path: msrps:intra.example.com:9000/jui787s2f \
msrps:alice.example.com:9892/98cjs
-------mnbvw$
MSRP mnbvw 200 OK
To-Path: msrps:intra.example.com:9000/jui787s2f \
msrps:alice.example.com:9892/98cjs
From-Path: msrps:extra.example.com
Authorization:
Use-Path: msrps:extra.example.com:9000/mywdEe1233 \
msrps:intra.example.com:9000/jui787s2f
-------mnbvw$
MSRP mnbvw 200 OK
To-Path: msrps:intra.example.com:9000/jui787s2f
From-Path: msrps:alice.example.com:9892/98cjs \
msrps:extra.example.com
Authorization:
Use-Path: msrps:extra.example.com:9000/mywdEe1233 \
msrps:intra.example.com:9000/jui787s2f
-------mnbvw$
5.1.2 Sending requests
The procedure for forming SEND and REPORT requests is identical for
clients whether relays are involved or not. The specific procedures
are described in section 6 of the core MSRP protocol.
As usual, once the next-hop URI is determined, the client MUST find
the appropriate address, port, and transport to use and then check if
there is already an existing suitable connection to the next-hop
target. If so, the client MUST send the request over the most
Jennings & Mahy Expires January 14, 2005 [Page 13]
Internet-Draft MSRP Relays July 2004
suitable connection. Suitability MAY be determined by a variety of
factors such as measured load and local policy, however in most
simple implementations a connection will be suitable if it exists and
is in an active state.
5.1.3 Receiving Requests
The procedure for receiving requests is identical for clients whether
relays are involved or not.
5.1.4 Managing Connections
Clients should open connection whenever they wish to deliver a
request and no suitable connection exists. For client to client
connections, a client should close a connection when there are no
longer any sessions associated with the connection. For connections
to relays, the client should leave a connection up until no sessions
are using the connection for a locally defined period of time, which
defaults to 5 minutes for foreign relays and one hour for the
client's relays.
5.2 Relay behavior
5.2.1 Handling Incoming Connections
5.2.2 Generic request behavior
Upon receiving a new request, relays first verify the validity of the
request. Relays then examine the first URI in the To-Path header and
remove this URI if it matches a URI corresponding to the relay. The
relay performs Authorization to determine if the final target is a
URI under its control or from a URI under its control.
5.2.3 Receiving AUTH requests
When a relay receives an AUTH request, it must digest challenge the
request. Once the challenge is complete, it MUST provide a URI that
can be used in future route headers. When the route URI is received
in future messages. It MUST verify that this URI was issued by this
relay. It MUST ensure that the message is either being forwarded
from an entity that did the AUTH request that resulted in this URI or
it is being forwarded to the the entity that did the AUTH request
that resulted in this URI.
If there are additional URIs in the To-Path header, the relay
attempts to forward the AUTH request to the remaining relays. The
relay MUST verify that the sender is authorized to route through this
Jennings & Mahy Expires January 14, 2005 [Page 14]
Internet-Draft MSRP Relays July 2004
relay to the target.
The relay does not necessarily needs to save state to meet these
requirements. One way that a relay could implement this is the
following. When an AUTH request arrives, the relay concatenates the
current time, the identity of the sender of the AUTH request, the
identity of the previous hop the request came from. It then takes
the concatenates string and encrypts it with a key only the relay
knows and uses this for form the user portion of the sims URI that it
returns. Later when it receives a URI, it can decrypt this
information and use it to decide if the request should be forwarded
or not. If the relay is actually several servers that share a DNS
name, the URI may also encrypt which server actually has the
connection to the client.
When a relay receive an AUTH request, it must authenticate the client
that sent it with digest, it must also authenticate the previous hop
that send the message to it. When previous hop was a relay this is
done with the mutual TLS while when the previous hop was a client
mutual TLS MAY be used it is available or the client authorization
from the digest is used. The relay will generate the base URI of a
family of URIs, each of which allows messages to be forwarded to and
from this client. If the previous hop was authenticated by mutual
TLS, then the URI MUST be valid to route across any connection the
relay has to the previous hop relay. If the previous hop was not
authenticated by mutual TLS, then the URI MUST only be valid to route
across the same connection that the AUTH was received on. If this
connection is closed then reopened, the URI MUST NOT be valid. Valid
to route means that when the relay receives a messages that contains
this URI, if the message it going to element that was the previous
hop in the AUTH, then the relay can forward it and if the messages is
coming from previous hop in the AUTH, then the relay can forward it
to any location, otherwise the RELAY must discard the message and MAY
send a REPORT indicating the auth URI was bad. If the AUTH request
contains an Expires header, then the relay MUST ensure that the URI
is not valid to route after the expiry time.
[*** NOTE: Consider moving to another section ***]
It is possible to implement all of the above requirements without the
relay saving any state. When a relay starts up it could pick a
crypto random 128 bit password (K) and 128 bit initialization vector
(IV). If the relay was actually a NDS farm, all the machines in the
farm would need to share the same K. When an ATUH request was
received the relay form a string that contains: the expiry time of
the URI, an indication if the previous hop was mutual TLS
authenticated or not and it it was, the name of the previous hop, if
it was not the identifier for the connection which received the AUTH
Jennings & Mahy Expires January 14, 2005 [Page 15]
Internet-Draft MSRP Relays July 2004
request. This string would be padded by appending a byte with the
value 0x80 then adding zero or more bytes with the value of 0x00
until the string length is a multiple of 16 bytes long. A new random
IV vector would be selected (it needs to change because it forms the
salt) and the padded string would be encrypted using AES-CBC with a
key of K. The IV and encrypted data and an SPI (security parameter
index) that changed each time K changed would be base 64 encoded and
form the user portion of the request URI. The SPI allows the key to
be changed and for the system to know which K should be used. Later
when the relay received this URI, it could decrypt it and check the
current time was before the expiry time and check that the messages
was coming from or going to the connection or location specified in
the URI. Integrity protection is not required because it is
extremely unlikely that random data that was decrypted would result
in a valid location that was the same as the messages was routing to
or from. When implementing something like this, implementers should
be careful not to use a scheme like EBE that would allows portion of
encrypted tokens to be cut and paste into others.
Note: A successful AUTH response returns a Route header which
contains a base MSRP URI that the client can use to create a number
of different URIs which are all associated with the current
connection.
5.2.4 Forwarding SEND requests
If an incoming SEND request Report-Success header is "yes", a MSRP
relay that receives that SEND request MUST respond with a final
response immediately. A 200-class response indicates the successful
receipt of a message fragment, but does not mean that the message has
been forwarded on to its next hop. The final response to the SEND
MUST be sent to the previous hop, which could be a MSRP relay or the
original sender of the SEND request.
If there is a problem further processing the SEND request and the
Report-Sucess header is "yes" or "partial", the relay MUST respond
with an appropriate error response back to the previous hop.
[Add more reporting requirements here].
The MSRP relay MAY further break up the message fragment received in
the SEND request into smaller fragments and forward them to the next
hop in separate SEND requests. It MAY also combine message fragments
received before or after this SEND request, and forward them out in a
single SEND request to the next hop identified in the Hops header.
The MSRP relay MUST NOT combine message fragments from SEND requests
with different values in the Message-ID header.
Jennings & Mahy Expires January 14, 2005 [Page 16]
Internet-Draft MSRP Relays July 2004
The MSRP relay MAY choose whether to further fragment the message, or
combine message fragments, or send the message as is, based on some
policy which is administered, or based on the network speed to the
next hop, or any other mechanism.
If the MSRP relay has knowledge of the byte range that it will
transmit to the next hop, it SHOULD update the Byte-Range header in
the SEND request appropriately.
Before forwarding the SEND request to the next hop, the MSRP relay
MUST inspect the first URI in the To-Path header. If it indicates
this relay, the relay removes this URI from the To-Path header and
inserts this URI in the From-Path header before any other URIs.
5.2.5 Forwarding non-SEND requests
An MSRP relay that receives any request other than a SEND request
(including new methods unknown to the relay), first follows the
validation and authorization rules for all requests in Section x.y.
Then the relay moves its URI from the beginning of the To-Path
header, to the beginning of the From-Path header and forwards the
request on to the next hop. It MUST use the most suitable conection,
etc, etc.. If no suitable connection exists, the relay opens a new
connection.
5.2.6 Forwarding Responses
Relays receiving a response, first check the transaction of the
response. If the response is a positive response, and the relay is
unaware of this transaction, the response MUST be dropped. Likewise
if the message is unparsable, the relay MUST drop the response. If
the response matches an existing transaction, the transaction state
MUST be deleted. The relay MUST verify that the first URI in the
To-Path corresponds to it. If not, the response SHOULD be dropped.
If there are additional URIs in the To-Path header, the relay can
then move its URI from the list To-Path header, insert its URI in
front of any other URIs in the From-Path header, and forward the
response to the next URI in the To-Path header. The relay sends the
request over the best connection which corresponds to the next URI in
the To-Path header. If this connection has closed, then the response
is silently discarded.
[Need to add text on failure report handling here] If the response
is a negative response, the relay may need to send a REPORT
indicating the nature of the failure.
Jennings & Mahy Expires January 14, 2005 [Page 17]
Internet-Draft MSRP Relays July 2004
5.2.7 Managing Connections
Relays should keep connection open as long as possible. If a
connection has not been used in a significant time (many minutes) it
could be closed. If the relay runs out of resource and must close
connections, it should first stop accepting new connections from
clients then start closing connections on a least recently used
basis.
5.2.8 Forwarding unknown requests
Requests with an unknown method are forwarded as if they were REPORT
requests.
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [5].
AUTHm = %x41.55.54.48 ; AUTH in caps
Method = SENDm / REPORTm / AUTHm
/ ext-method
Authentication-Info = "Authentication-Info" HCOLON ainfo
*(COMMA ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = LDQUOT *LHEX RDQUOT
Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = rquest-uri ; Equal to request-uri as specified
by HTTP/1.1
message-qop = "qop" EQUAL qop-value
Jennings & Mahy Expires January 14, 2005 [Page 18]
Internet-Draft MSRP Relays July 2004
cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
LHEX = DIGIT / %x61-66 ;lowercase a-f
; Some elements (authentication) force hex alphas to be lower case.
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge
other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param)
digest-cln = realm / domain / nonce
/ opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI
*( 1*SP URI ) RDQUOT
URI = MSRP-URI / anyURI
nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess"
/ token )
qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT
qop-value = "auth" / token
Expires = "Expires" ":" SP 1*DIGIT
Use-Path = "Use-Path" ":" SP URI *(SP URI)
7. Finding MSRP Servers
When resolving a an MSRP URI which contains an explicit port number,
an MSRP node follows the rules in section 4.4 of MSRP. MSRP URIs
Jennings & Mahy Expires January 14, 2005 [Page 19]
Internet-Draft MSRP Relays July 2004
exchanged in SDP and in To-Path and From-Path headers in non-AUTH
requests MUST have an explicit port number. The following rules
allow MSRP clients to discover MSRP relays more easily in AUTH
requests.
If the hostport of an msrps: URI is an IPv4 address or an IPv6
reference and no port number is provided, use the default port number
assigned by IANA. If the hostport is a domain name and an explicit
port number is provided, attempt to lookup a valid address record (A
or AAAA) for the domain name. Connect using the TLS over the default
transport (TCP) with the default port number.
If a domain name is provided, but no port number, perform a DNS SRV
[6] lookup for and select the entry with the highest weight. If no
SRV records are found, try an address lookup (A or AAAA) using the
default port number procedures described in the previous paragraph.
Note that AUTH requests MUST only be sent over a TLS-protected
channel. An SRV lookup in the example.com domain might return:
;; in example.com. Pri Wght Port Target
_msrps._tcp IN SRV 0 1 9000 server1.example.com.
_msrps._tcp IN SRV 0 2 9000 server2.example.com.
If implementing a relay farm, it is RECOMMENDED that each member of
the relay farm have an SRV entry. If any members of the farm have
multiple IP addresses (for example an IPv4 and an IPv6 address), each
of these addresses SHOULD be registered in DNS as separate A, AAAA,
or A6 records corresponding to a single target.
8. Security Considerations
This section first describes the security mechanisms available for
use in MSRP. Then the threat model is presented. Finally we list
implementation requirements related to security.
8.1 Using HTTP Authentication
AUTH requests SHOULD be authenticated using HTTP authentication.
HTTP authentication is done as described in [RFC 2617], with the
following exceptions. Basic authentication MUST NOT be used. A qop
value of auth-int MUST NOT be used as the AUTH requests are integrity
protected by TLS and there is no body to protect. Note that unlike
in some usages of HTTP Authentication (for example, SIP), the uri
parameter in the Authorize header is the same as the Request-URI in
the request line of the MSRP parcel of the AUTH request. Note the
BNF in RFC-2617 has an error--the value of the uri parameter MUST be
in quotes. The BNF in this document is correct, as are the examples
in RFC 2617.
Jennings & Mahy Expires January 14, 2005 [Page 20]
Internet-Draft MSRP Relays July 2004
8.2 Using TLS
TLS is used to authenticate relays to senders and to provide
integrity and confidentiality for the headers being transported.
MSRP client and relays MUST support TLS. Clients and relays MUST
support the TLS ClientExtendedHello extended hello information for
server name indication as described in RFC 3546 [7]. A TLS
cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [8] MUST be supported
(other cipher-suites MAY also be suported). Relays must act as TLS
servers and present a certificate with their identity in the
SubjectAltName using the choice type of dnsName. Relay to relay
connections MUST use TLS and client to relay communications MUST use
TLS for AUTH requests and responses.
Note that when relays are involved in a session, TCP without TLS
is only used when a relay of one user connects directly to an MSRP
endpoint of another user who does not use relays.
8.3 Threat Model
This section discuses the threat model and the broad mechanism that
must come into place to secure the protocol. The next section
describes the details of how the protocol mechanism meet the broad
requirements.
MSRP allows two peer to peer clients to exchange messages. Each peer
can select a set of relays to perform certain policy operation for
them. This combined set of relays is referred to as the route set.
There often exists a channel outside of MSRP, such as out-of-band
provisioning or an explicit rendezvous protocol such as SIP, that can
securely negotiate setting up the MSRP session and communicate the
route set to both clients. A client may trust a relay with certain
types of routing and policy decisions but it might or might not trust
the relay with all the contents of the session. For example, a relay
being trusted to look for viruses would probably need to be allowed
to see all the contents of the session. A relay that helped deal
with firewall traversal of the ISPs firewall would likely not be
trusted with the contents of the session but would be trusted to
correctly forward information.
Clients need to be able to authenticate that the relay they are
communicating with is the one they trust. Likewise, relays need to
be able to authenticate the client is the authorized client for them
to forward information to. Clients need the option of ensuring
information between the relay and the client is integrity protected
and confidential to elements other than the relays and clients. To
simplify the number of options, traffic between relays must always be
integrity protected and encrypted regardless of if the client request
it or not. There is no way for the clients to tell the relays what
Jennings & Mahy Expires January 14, 2005 [Page 21]
Internet-Draft MSRP Relays July 2004
strength of crypto to use between relays other than the clients to
choose to use relays that are operated by people requiring an
adequate level of security.
The system also need to stop the messages from being directed to
relays that are not supposed to see them. To keep the relays from
being used in DDoS attacks, the relays must not forward messages
unless they have a trust relationship with either the client sending
or receiving the message and that they only forward that message if
it is coming from or going to the client they have the trust
relationship with. If a relay has a trust relationship with the
client that is the destination of the message, it should not send the
message anywhere except the client that is the destination.
Some terminology used in this discussion is SClient is the client
sending a message and RClient is the client receiving a message.
SRelay is a relay the sender trusts and RRelay is a relay the
receiver trusts. The message will go from SClient to SRelay1 to
SRelay2 to RRelay2 to RRelay1 to RClient.
8.4 Security Mechanism
Confidentiality and Privacy from elements not in the route set is
provided by using TLS on all the transports. If a client decided to
not use TLS that is it's choice but relays must use TLS. Clients
must implement TLS.
The relays authenticate to the clients using TLS (but don't have to
do mutual TLS). The clients authenticate to the relays using HTTP
Digest inside of TLS. Relays authenticate to each other using mutual
TLS.
The clients can protect the contents so that the relays can not see
them by using S/MIME encryption. End to end signing is also possible
with S/MIME.
The complex part is making sure that relays do not send messages
place where they should not. This is done by having the client
authenticate to the relay and having the relay return a token.
Messages that contain this token can be relayed if they come from the
client that got the token or if they are being forwarded towards the
client that got the token. The tokens must only ever be seen by
things in the route set or other elements that at least one of the
parties trusts. If some 3rd party discovers the token that RRelay2
uses to forward messages to RClient, then that 3rd party can send as
many messages as they want to RRelay2 and it will forward them to
RClient. The 3rd party can not cause them to be forwarded anywhere
except to RClient eliminating the open relay problems. SRelay1 will
Jennings & Mahy Expires January 14, 2005 [Page 22]
Internet-Draft MSRP Relays July 2004
not forward the message unless it contains a valid token.
When SClient goes to get a token from SRelay2, this request is
relayed through SRelay1. SRelay authenticates that it really is
SClient requesting the token but it generates a token that is only
valid for forwarding messages to or from SRelay1. SRelay two knows
it is connected to SRelay1 because of the mutual TLS.
The tokens are carried in the user portion of the MSRP URLs.
Issues: How to tokens expire - rekeying. Will probably use Expire
header on AUTH response. Token MAY be valid for between 10 minutes
and 24 hours with 1 hour recommended. Both sides need to do a SIP
re-invite to set up new tokens before the old one expires.
Issues: Token good for single session or for all session
Note: tokens are only required for relays, not clients or note
takers.
TODO talk about example from client to client and from Client A, then
to a relay that A uses, RA, then on to client B.
8.5 Preventing Spam and Denial of Service Attacks
While this specification already implements a number of significant
improvements to prevent unsolicited messaging and Denial of Service,
additional mechanisms are envisioned being useful in the future. The
402 Payment Required and 409 Puzzle Required response codes are
reserved for future use and may be useful to further discourage
unsolicited messages.
9. IANA Considerations
This document introduces no requirements for IANA.
10. Example SDP with multiple hops
A sample SDP offer for a MSRP session could look like:
c=IN IP4 invalid.none
m=message 9 msrp *
a=accept-types: message/cpim text/plain text/html
a=path:msrp:a.example.com:1234/agic456;tcp
In this offer Alice wishes to receive MSRP messages at a.example.com.
She wants to use TCP as the transport for the MSRP session. She can
Jennings & Mahy Expires January 14, 2005 [Page 23]
Internet-Draft MSRP Relays July 2004
accept message/cpim, text/plain and text/html message bodies in SEND
requests. She does not need a relay to setup the MSRP session.
To this offer, Bob's answer could look like:
c=IN IP4 invalid.none
m=message 9 msrp *
a=accept-types: message/cpim text/plain
a=path:msrps:relay.example.com:9000/hjdhfha;tcp \
msrps:bob.example.com:1234/fuige;tcp
Here Bob wishes to receive the MSRP messages at bob@bob.example.com.
He can accept only message/cpim and text/plain message bodies in SEND
requests and has rejected text/html offer made by Alice. He wishes
to use a relays for the MSRP session - relay.example.com.
11. Acknowledgments
Many thanks to the following members of the SIMPLE WG for spirited
discussions on session mode: Ben Campbell, Jonathan Rosenberg,
Robert Sparks, Paul Kyzivat, Allison Mankin, Jon Peterson, Brian
Rosen, Dean Willis, Adam Roach, Aki Niemi, Hisham Khartabil, Juhee
Garg, Pekka Pessi, and Chris Boulton
12. References
12.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
Jennings & Mahy Expires January 14, 2005 [Page 24]
Internet-Draft MSRP Relays July 2004
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003.
[8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[11] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[13] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989.
[14] Troost, R., Dorner, S. and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[15] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[17] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[18] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
12.2 Informative References
[19] Mahy, R., "Benefits of Session-Mode Instant Messaging",
Jennings & Mahy Expires January 14, 2005 [Page 25]
Internet-Draft MSRP Relays July 2004
draft-mahy-simple-why-session-mode-00.txt (work in progress),
February 2004.
[20] Campbell, B., "Instant Message Sessions in SIMPLE",
draft-ietf-simple-message-sessions-02 (work in progress), Oct
2003.
[21] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003.
[22] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[23] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[24] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[25] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[26] Mahy, R., "Relay Requirements for Session-Mode Instant
Messaging", draft-mahy-simple-session-relay-reqs-00.txt (work
in progress), February 2004.
Authors' Addresses
Cullen Jennings
Cisco Systems, Inc.
170 West Tasman Dr.
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 527-9132
EMail: fluffy@cisco.com
Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.com
Jennings & Mahy Expires January 14, 2005 [Page 26]
Internet-Draft MSRP Relays July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jennings & Mahy Expires January 14, 2005 [Page 27]
Internet-Draft MSRP Relays July 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings & Mahy Expires January 14, 2005 [Page 28]
