[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]