SIPPING WG R. Mahy
Internet-Draft Cisco Systems, Inc.
Expires: December 30, 2004 Jul 2004
Pros and Cons of allowing SIP Intermediaries to add MIME bodies
draft-mahy-sipping-body-add-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The SIPPING Working Group has developed requirements for session
policy (including bandwidth and codec restrictions, logging, and
middlebox traversal), request history, and identity. This document
discusses the pros and cons of allowing intermediaries to add SIP
message bodies to address these requirements. It is intended to
provoke serious discussion rather than as a complete proposal.
Mahy Expires December 30, 2004 [Page 1]
Internet-Draft SIP body addition Jul 2004
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the body addition proposal . . . . . . . . . . . . 6
5. Applications with and without body modification . . . . . . . 9
5.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Session codec / bandwidth policy checking . . . . . . . . 10
5.3 Midcom-style firewall traversal . . . . . . . . . . . . . 10
5.4 NAT traversal (including v4/v6 translators) . . . . . . . 10
5.5 3rd-party Asserted Identity . . . . . . . . . . . . . . . 10
5.6 Request History . . . . . . . . . . . . . . . . . . . . . 11
5.7 3rd Party Authentication Service . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
9.2 Informational References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Mahy Expires December 30, 2004 [Page 2]
Internet-Draft SIP body addition Jul 2004
1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
2. Introduction
Certain classes of applications the SIP and SIPPING WGs are
considering ([9], [10], [11], [12]), lend themselves casually to an
approach where intermediaries can inspect, add, or modify bodies.
Unfortunately, this practice as currently implemented is completely
incompatible with the S/MIME [3] end-to-end security mechanisms
specified in the core SIP specification (RFC 3261 [1]), and
consequently an explicit violation of the spec. The SIP community is
at an impasse regarding how these classes of feature need to be
implemented. This document attempts to present an overview of the
two major proposals for moving forward.
One proposal suggests that body additions (as opposed to
modifications) can be done safely by SIP intermediaries if these
bodies are optional in nature and if certain restrictions are placed
on which intermediaries are allowed to add bodies and under what
circumstances. This proposal would require a relaxation of one
sentence in the SIP specification and would effectively enable a
generic mechanism which could be used for a variety of applications.
This mechanism would not interfere with user agents which do
end-to-end security directly. Intermediaries which could add bodies
could sign or encrypt these as the product of a specific
intermediary. The receiving user agent would be responsible for
verifying the validity and trustworthiness of each body part.
Another proposal suggests that allowing intermediaries to add bodies
introduces unneeded complexity and a handful of other undesirable
properties. These undesirable properties could be avoided by
addressing each of the requirements individually while carefully
limiting the scope of some of these applications. In addition, this
proposal accommodates a model where a new intermediary role called an
Authentication Service which has a direct TLS [4] connection and a
specific trust relationship with one of the user agents could make
change to bodies on behalf of that user agent if also performing
end-to-end security operations on its behalf.
In addition to supporting the required applications in the presence
of true end-to-end security, it is highly desirable to support a
mechanism that allows specific intermediaries to safely sign and
verify and possibly encrypt and decrypt requests and responses on
behalf of user agents which have not implemented S/MIME. This allows
Mahy Expires December 30, 2004 [Page 3]
Internet-Draft SIP body addition Jul 2004
for a migration path from existing implementations to a completely
end-to-end environment in a safe manner.
3. Topologies
An explicit policy fetch allows user agents to fetch a policy
document directly from their intermediaries, for example using the
approach described in [14] and [13]. This significantly reduces, but
does not completely eliminate the need for policy "corrections" by
specific intermediaries for specific sessions. The remainder of this
section assumes that available policy information available in the
local domain has already been exhausted. Note that through
configuration or prior negotiation, Alice and atlanta.com probably
have few policy conflicts, and Bob and biloxi.com probably have few
policy conflicts. The bulk of policy conflicts are likely to be
between Alice or atlanta.com and Bob or biloxi.com.
This section explores the possible paths that a request can take from
sip:alice@phone2.atlanta.com to sip:bob@pc1.biloxi.com and the policy
implications.
Full Redirect Model: This topology results in Alice sending a request
to sip:bob@biloxi.com, which redirects her request to
bob@pc1.biloxi.com. Alice opens a new connection directly to
pc1.biloxi.com and sends her request directly with no intermediate
proxies . There is no opportunity for either atlanta.com or
biloxi.com to enforce session policy here at all, since neither is
involved in further signaling.
INVITE sip:bob@biloxi.com SIP/2.0
[biloxi.com redirects]
SIP/2.0 302 Moved
Contact: <sip:bob@pc1.biloxi.com>
[Alice retries request to new target URI]
INVITE sip:bob@pc1.biloxi.com SIP/2.0
Triangle Signaling Model: Alice opens a connection to biloxi.com
which routes Alice's request to bob@pc1.biloxi.com. This offers an
opportunity for biloxi.com to issue a repairable error response which
Alice could fix and retry. This is the most elegant toplogy because
it has the simplest security characteristics. Unfortunately this
model does not allow atlanta.com to influence requests from Alice.
Many organizations require policy influence over requests which
originate within their networks.
Mahy Expires December 30, 2004 [Page 4]
Internet-Draft SIP body addition Jul 2004
INVITE sip:bob@biloxi.com SIP/2.0
[biloxi.com retargets]
INVITE sip:bob@pc1.biloxi.com SIP/2.0
Trapezoid Signaling Model: Alice routes its request to bob@biloxi.com
through atlanta.com. Then biloxi.com retargets the requests and
forwards it to bob@pc1.biloxi.com. This model allows both
atlanta.com and biloxi.com to influence policy on new sessions.
There are still variations of how atlanta.com and biloxi.com can
influence the session.
INVITE sip:bob@biloxi.com SIP/2.0
Route: sip:atlanta.com;lr
[atlanta.com forwards the request to biloxi.com]
INVITE sip:bob@biloxi.com SIP/2.0
[biloxi.com retargets]
INVITE sip:bob@pc1.biloxi.com SIP/2.0
One way to allow proxies to influence policy in the trapezoid model
causes an extra round trip to allow Alice to "consent" to each
proposed policy change. For example, atlanta.com could issue a
repairable error response to influence a new request, and then
biloxi.com could likewise issue a repairable error response to add
its policy requirements. This model results in many messages and can
result in significant additional delay due to extra round trips. In
addition, information which is potentially private between biloxi.com
and Bob is sent to Alice. Also, Alice may be asked to forward opaque
or encrypted data from an intermediary with whom Alice has no trust
relationship. It hard to imagine how Alice could decide on what
basis to "consent" to include such content.
Alice -> atlanta.com
[atlanta.com asks Alice to comply with specific policy]
Alice -> atlanta.com -> biloxi.com
[biloxi.com asks Alice to comply with specific policy
or forward opaque data to Bob]
Alice -> atlanta.com -> biloxi.com -> bob@pc1.biloxi.com
Alternatively, many existing deployments "piggyback" extra
information at atlanta.com and biloxi.com (or modify the MIME [5]
content). In addition to expressly violating RFC 3261 [1] and
breaking any end-to-end security used by Alice and Bob, this model
can cause Alice or Bob to receive MIME bodies with Content-Types
Mahy Expires December 30, 2004 [Page 5]
Internet-Draft SIP body addition Jul 2004
which they don't understand (This is known as the "415" problem after
the 415 response code). Imagine Alice sends a requests including
only the text/foo MIME type, but receives a 415 Unacceptable response
which includes text/foo as an acceptable MIME type. Alice has no
information about what happened (Bob rejected the text/bar MIME type
inserted by atlanta.com), and cannot do anything to repair the
"error".
The compromise approach described in the next section allows
atlanta.com to "challenge" Alice with repairable error responses to
comply with atlanta's policies, while biloxi.com can add a message
body intended for consumption by Bob. This may be a technically
workable solution, but requires complex MIME and authorization
processing by intermediaries that participate in policy. This
approach would still require a relaxation of Section 16.6, Step 1 of
RFC 3261 [1].
Alice -> atlanta.com
[atlanta.com asks Alice to comply with specific policy]
Alice -> atlanta.com -> biloxi.com
[biloxi adds its policy requests to the request]
-> Bob
Pentagram Signaling Model: In this model, extra intermediaries who
are not directly associated with either Alice or Bob are included.
This model is to be avoided as it dramatically increases the
complexity of the security required.
Alice -- atlanta.com -- provider.net -- biloxi.com -- Bob
4. Overview of the body addition proposal
Of prime importance to the body addition proposal is insuring that
the mechanism can be added in a backwards compatible way. To
facilitate backward compatibility, the body addition proposal
introduces a new option-tag called "repack" which indicates that a
user agent supports multipart MIME [6] and allows bodies to be
addressed to and from intermediaries. User Agents include this token
in a Supported header when registering along with an Accept header
with all the MIME types the User Agent supports.
When a User Agent supports body repacking, we assume that the
wrapping of the outermost MIME type in the SIP body is not relevant
for the authentication purposes. Each of the MIME parts inside the
outermost part can stand alone as a separate message. Each of these
Mahy Expires December 30, 2004 [Page 6]
Internet-Draft SIP body addition Jul 2004
MIME parts MUST have a Content-Disposition MIME header. If the MIME
part is sent to or from an intermediary (instead of the original UAC
or the final UAS), the Content-Disposition header MUST contain a src
or dest parameter indicating the source or destination of the
request.
If the UAC needs to include some content for a specific intermediary,
it indicates this by adding a content parameter to the Route header
field value which corresponds to the target intermediary. The
content parameter contains a content ID [7] which is referenced in
the appropriate body. (For illustrative purposes, a band of
asterisks (*****) surrounds content that would actually be signed
or encrypted using S/MIME).
INVITE sip:bob@biloxi.example.com
From: <sip:alice@atlanta.example.com>
To: <sip:bob@biloxi.example.com>
Route: <sip:atlanta.example.com;lr>;content="lki290s8"
...
Content-Type: multipart/mixed;boundary=bar
--bar
Content-ID: <lki290s8>
Content-Disposition: policy ;handling=optional ;dest="sip:atlanta.example.com"
*****
* ...
*****
--bar
Content-Disposition: session ;handling=required
*****
* Content-Type: application/sdp
* ...
*****
--bar
When an intermediary operating on the UACs behalf requires additional
information in a request it needs to send a repairable error response
asking for the appropriate additional information. We can define a
new response code for this, for example "497 Policy Error". However,
the UAC and intermediaries operating on the UACs behalf are expected
to be well matched, for example mutually configured using session
independent policies, so this extra round trip should not happen very
often.
When an intermediary operating on behalf of the UAS needs to include
additional information about the request, it can add a body part to
the message if it knows that the UAS supports the repack option and
that any required body types that were added are acceptable to the
Mahy Expires December 30, 2004 [Page 7]
Internet-Draft SIP body addition Jul 2004
UAS. In most cases, the UAS registered with the repack option-tag in
a Supported header or is administratively configured to known that
the UAS supports the extension. In addition, the UAS proxy can
include any MIME types as long as the handling parameter (in the
Content-Disposition header) indicates the body part is optional. In
addition, if the intermediary is collocated with the registrar for
the UAS, the intermediary can observe the MIME types listed in the
Accept header and send these even as "required" body parts. Any body
parts added by the intermediary need to have a src parameter which
corresponds the SIP URI of the intermediary that added the body part.
In addition, these MIME parts MUST be signed using S/MIME using the
key from a certificate which contains a SubjectAltName field which
exactly matches the SIP URI in the src parameter.
Content-Disposition: policy ;handling=optional ;src="sip:biloxi.example.com"
*****
* Content-Type: application/sip-session-policy+xml
* ...
*****
When a UAC receives a request, it MUST examine the src parameter for
each body type that it understands. If any of the body parts are
signed it then must discard body parts from untrusted sources, or
improperly signed body parts. The UAC can then clearly distinguish
the body parts which were signed by the UAC from the body parts that
were signed by the a proxy operating on behalf of the UAS.
When the UAS sends a response, intermediaries operating on behalf of
the UAS can examine the response and forward the response along.
Typically the response will cooperate with the policies that were
just sent in the request, but if not, the intermediary can send a 500
Server Error response to the request and drop the illegal response it
received from the UAS. Intermediaries can similarly add body parts
to the response as long as the UAC indicated support for the repack
option-tag and all "required" MIME types are acceptable to the UAC.
Finally, when the UAC receives the response, it MUST examine the src
parameter for each body type that it understands, discard untrusted
or improperly signed body parts and act on body parts sent by the UAS
differently from body parts added by its intermediary.
This proposal addresses the three most serious technical concerns
with adding bodies. The proposal is backward safe and can operate
even if only one side supports the extension. It is impossible for
the UAC to receive a 415 Not Acceptable response due to content
inserted by an intermediary. The User Agents can distinguish which
body parts were sent by the other User Agent and which were added by
an intermediary.
Mahy Expires December 30, 2004 [Page 8]
Internet-Draft SIP body addition Jul 2004
Unfortunately the proposal requires very sophisticated MIME parsing
and verification/generation of multiple S/MIME signatures per message
on both User Agents and intermediaries which decide to add bodies.
This requires that UACs either sign all bodies, no bodies, or that
they trust an appropriate service to do so (and that the protocol
support necessary for this is available). On first glance, it may
also seem to increase message size and processing time, however
initial analysis does not suggest any significant difference between
this approach and any other proposals in this regard. Note also,
that this approach opens up opportunities for intermediaries to abuse
this functionality for so-called "middle-to-middle" communications
which can introduce a significant burden on other SIP intermediaries
and the infrastructure of the Internet.
Finally, this approach can be modified slightly to allow a 3rd party
user agent to sign, verify, encrypt, and decrypt SIP messages on
behalf of a user agent which does not support end-to-end security.
This SIP node would keep credentials for the address-of-record of the
user agent and apply these to each of its messages. It could handle
all the authorization and verification duties (for example, throwing
away bodies inserted by malicious intemediaries) normally required of
user agents under this proposal.
5. Applications with and without body modification
5.1 Logging
This application [10] requires an intermediary to inspect SIP message
bodies. This can be session descriptions [18] which reference
specific streams, or in the case of the MESSAGE method [22], actual
content. If this session description or content is encrypted, either
the logging service needs to receive a copy of the Content Encryption
Key or it needs to receive another copy of the message.
It is clear that if Alice wants to provide a copy of Content
Encryption Key to her logging proxy she can, but less clear how she
can (directly or indirectly) provide this information to Bob's
logging proxy. Bob could provide this information to its proxy, but
this requires that either Bob's proxy ask for this information (and
that Alice provide it) or that Bob provide the Content Encryption Key
to his proxy in a way that is easy to correlate.
For this application, it is not necessary for an intermediary to ever
add its own body (commonly called end-to-middle [15] security or
e2m). Addressing some bodies from a user agent to an intermediary
instead of the other user agent could be used here, but this
application could be accomodated nearly as easily without addressing
bodies at intermediaries.
Mahy Expires December 30, 2004 [Page 9]
Internet-Draft SIP body addition Jul 2004
5.2 Session codec / bandwidth policy checking
This application requires an intermediary to inspect session
descriptions, but does not require them to be changed. This is
problematic if the session description is encrypted however,
especially if the session description contains keying information
[24] which Alice or Bob don't want to be provided to an intermediary
and is not otherwise required.
Directing a copy of a portion of the session description at an
intermediary (e2m) could mitigate the privacy lost here, but does not
require body addition.
5.3 Midcom-style firewall traversal
Like the previous application, a firewall traversal intermediary (ex:
using the MIDCOM architecture [19]) needs access to the transport
protocols, IP addresses, and ports in use for each m-line. Again, if
the session description is encrypted and contains sensitive keying
material, it would be desirable to provide an additional copy of this
information in another body using e2m. No body additions by
intermediaries are required for this application either.
5.4 NAT traversal (including v4/v6 translators)
NAT [20] traversal using protocols such as STUN [8] and ICE [25]
would not normally require body modification, addition, or even
inspection. (An intermediary might need to provide an address of a
STUN server for example.) NAT traversal using a MIDCOM-style
approach however introduces a tremendous amount of complexity.
This application is fairly complex with the body modification
proposal (a specific proposal is described in the next paragraph,
which does ), and even more challenging when body modifications are
not permitted. However, it may be prudent for the SIP community to
completely reject this as a valid application of the SIP session
policy mechanism when superior mechanisms for NAT traversal are
available.
[Description of MIDCOM-style NAT traversal with body addition
approach]
5.5 3rd-party Asserted Identity
This application involves an intermediary providing an assertion of
the identity of the sender of the message. A proposal which
describes this concept using a body (in this case an authenticated
identity body) is described in
Mahy Expires December 30, 2004 [Page 10]
Internet-Draft SIP body addition Jul 2004
<http://www.softarmor.com/wgdb/docs/draft-ietf-sip-identity-00.txt>.
A proposal which describes this concept using a header is [11]. Note
that the auth-id [16] body could be replaced with a different body to
allow unambiguous use in both requests and responses.
End-to-end identity could be provided in such a way to provide a
secure binding between the original Request-URI and a Contact header
provided. When used in a body, this would unfortunately require a
new Identity header anytime a Contact header changes (for example
when transitioning from a 2-party call to a SIP conference [26]).
5.6 Request History
This application involves an intermediary providing an assertion that
a request was retargetted. Request history using body addition [12]
is extremely natural. An auth-id body is provided for every
retargetting signed by the proxy performing that retargetting. This
provides an alternative way of binding an original Request-URI with a
provided Contact header.
History without body addition could be accomplished in one of three
ways. The Request-History header field value itself could contain a
cryptographic object similar to the current Identity proposal. The
Request-History service could be restricted so it can only be
provided by a server which also provides the Identity service (the
most common cases), Finally, request history could be provided as a
P-Header [21] only for use in certain administrative domains using a
technique similar to RFC 3325 [23] (P-Asserted-Identity) that
requires specific trust relationships.
5.7 3rd Party Authentication Service
This service signs, verifies, encrypts, and decrypts on behalf of a
user agent which cannot perform these functions itself. A third
party which performs these functions most definitely needs to inspect
and add MIME bodies. This third part however would have credentials
used on behalf of the user, and would presumably be reachable
directly over a secure channel (for example over a TLS connection).
This application is easily implemented using the body addition
proposal. If Alice needed a new request signed or encrypted she
would need to send her request to this server, which would return her
signed or encrypted content. She would then resend the request.
Bob's service could add a MIME body with the decrypted and verified
contents, and also encrpyt and/or sign Bob's response.
As an alternative to the body addition proposal, you could relax the
body modification requirement just for this specific application
which would be defined as a new SIP role with specific normative
Mahy Expires December 30, 2004 [Page 11]
Internet-Draft SIP body addition Jul 2004
behavior.
In either case, such a service could be collocated with a SIP
Credential Service [17] or an
<http://www.employees.org/~fluffy/ietf/draft-jennings-sipping-certs-02.html>
.
6. Security Considerations
Much to talk about here.
7. IANA Considerations
8. Acknowledgments
Thanks to Jon Peterson and Cullen Jennings for a hearty discussion.
9. References
9.1 Normative References
[1] 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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[8] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through
Mahy Expires December 30, 2004 [Page 12]
Internet-Draft SIP body addition Jul 2004
Network Address Translators (NATs)", RFC 3489, March 2003.
[9] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-01 (work in progress),
February 2004.
[10] Ono, K. and S. Tachimoto, "Requirements for End-to-middle
Security for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-e2m-sec-reqs-03 (work in progress), July
2004.
[11] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-02 (work in progress), May 2004.
[12] Barnes, M., "An Extension to the Session Initiation Protocol
for Request History Information",
draft-ietf-sip-history-info-02 (work in progress), February
2004.
[13] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-03
(work in progress), May 2004.
[14] Hilt, V., "Session-Independent Policies for the Session
Initiation Protocol (SIP)",
draft-hilt-sipping-session-indep-policy-01 (work in progress),
May 2004.
[15] Ono, K. and S. Tachimoto, "End-to-middle security in the
Session Initiation Protocol(SIP)",
draft-ono-sipping-end2middle-security-02 (work in progress),
May 2004.
[16] Peterson, J., "SIP Authenticated Identity Body (AIB) Format",
draft-ietf-sip-authid-body-03 (work in progress), May 2004.
[17] Jennings, C., "Certificate Management Service for SIP",
draft-jennings-sipping-certs-03 (work in progress), May 2004.
9.2 Informational References
[18] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[19] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
Mahy Expires December 30, 2004 [Page 13]
Internet-Draft SIP body addition Jul 2004
RFC 3303, August 2002.
[20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[21] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[23] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[24] Andreasen, F., Baugher, M. and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-06 (work in progress), July
2004.
[25] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-01 (work in progress), February 2004.
[26] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-03 (work in progress),
February 2004.
Author's Address
Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.com
Mahy Expires December 30, 2004 [Page 14]
Internet-Draft SIP body addition Jul 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mahy Expires December 30, 2004 [Page 15]