doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc5379.txt b/doc/rfc/rfc5379.txt
new file mode 100644
index 0000000..346e2ae
--- /dev/null
+++ b/doc/rfc/rfc5379.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Independent Submission                                       M. Munakata
+Request for Comments: 5379                                   S. Schubert
+Category: Informational                                          T. Ohba
+ISSN: 2070-1721                                                      NTT
+                                                           February 2010
+
+
+           Guidelines for Using the Privacy Mechanism for SIP
+
+Abstract
+
+   This is an informational document that provides guidelines for using
+   the privacy mechanism for the Session Initiation Protocol (SIP) that
+   is specified in RFC 3323 and subsequently extended in RFCs 3325 and
+   4244.  It is intended to clarify the handling of the target SIP
+   headers/parameters and the Session Description Protocol (SDP)
+   parameters for each of the privacy header values (priv-values).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5379.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+
+Munakata                      Informational                     [Page 1]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Semantics of Existing priv-values ...............................4
+   4. Target for Each priv-value ......................................5
+      4.1. Target SIP Headers for Each priv-value .....................5
+      4.2. Target SDP Parameters for Each priv-value ..................6
+      4.3. Treatment of priv-value Not Supported by the
+           Privacy Service ............................................7
+   5. Recommended Treatment of User-Privacy-Sensitive Information .....7
+      5.1. Target SIP Headers .........................................7
+           5.1.1. Call-ID .............................................7
+           5.1.2. Call-Info ...........................................8
+           5.1.3. Contact .............................................8
+           5.1.4. From ................................................9
+           5.1.5. History-Info .......................................10
+           5.1.6. In-Reply-To ........................................10
+           5.1.7. Organization .......................................11
+           5.1.8. P-Asserted-Identity ................................11
+           5.1.9. Record-Route .......................................12
+           5.1.10. Referred-By .......................................13
+           5.1.11. Reply-To ..........................................14
+           5.1.12. Server ............................................14
+           5.1.13. Subject ...........................................15
+           5.1.14. User-Agent ........................................15
+           5.1.15. Via ...............................................15
+           5.1.16. Warning ...........................................16
+      5.2. Target SDP Parameters .....................................16
+           5.2.1. c/m Lines ..........................................16
+           5.2.2. o Line .............................................17
+           5.2.3. i/u/e/p Lines ......................................17
+      5.3. Considerations for Non-Target SIP Headers/Parameters ......17
+           5.3.1. Identity/Identity-Info .............................17
+           5.3.2. Path ...............................................18
+           5.3.3. Replaces Header/Parameter ..........................18
+           5.3.4. Route ..............................................21
+           5.3.5. Service-Route ......................................21
+           5.3.6. Target-Dialog ......................................21
+   6. Security Considerations ........................................21
+   7. Acknowledgements ...............................................22
+   8. References .....................................................22
+      8.1. Normative References ......................................22
+      8.2. Informative References ....................................22
+
+
+
+
+
+
+
+Munakata                      Informational                     [Page 2]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+1.  Introduction
+
+   This document clarifies the privacy mechanism for the Session
+   Initiation Protocol (SIP) [RFC3261] defined in [RFC3323], which was
+   later extended in [RFC3325] and [RFC4244].  This document describes
+   the practical manner of operations of the privacy mechanism as a
+   guideline and does not change the existing privacy mechanism.
+
+   In RFC 3323, the semantics of the basic set of priv-values (header,
+   session, user, none, and critical) is defined, but there are some
+   ambiguities in regards to the target information to be obscured per
+   priv-value, which are not explicitly specified.  An ambiguity such as
+   this could result in different interpretations of privacy handling
+   for each of the priv-values defined, both at an entity setting a
+   Privacy header and at an entity processing a Privacy header, which
+   could have an adverse impact on interoperability.
+
+   Additional priv-values "id" and "history" are defined in RFCs 3325
+   and 4244, respectively.
+
+   In RFC 4244, the priv-value "history" is defined in order to request
+   privacy for History-Info headers, and the target to be obscured for
+   "history" priv-value is specified as only the History-Info headers.
+   In addition, the RFC clearly describes that History-Info headers are
+   also the target when "header"- and "session"-level privacy are
+   requested.
+
+   On the other hand, RFC 3325 defines the P-Asserted-Identity header
+   and a priv-value "id", which is used to request privacy for only the
+   P-Asserted-Identity header, but it does not specify how other priv-
+   values may impact the privacy handling of the P-Asserted-Identity
+   header.  Because of this lack of specification, it has been observed
+   that some implementations are suffering from the inability to achieve
+   the intended privacy due to discrepancies in interpretations.
+
+   This document tries to clarify the SIP headers and SDP parameters to
+   be obscured for each of the priv-values to alleviate the potential
+   interoperability issues already seen due to a lack of explicit text.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+Munakata                      Informational                     [Page 3]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   Note: This document is informational; therefore, it does not specify
+         any new normative behaviors of privacy mechanism.  All the RFC
+         2119 language in this document is derived from the normative
+         text in the existing RFCs, such as RFC 3323.
+
+   priv-value:
+         Values registered with IANA to be used in the Privacy header.
+         Registered priv-values are "header", "session", "user", "none",
+         and "critical" defined in [RFC3323]; "id" defined in [RFC3325];
+         and "history" defined in [RFC4244].
+
+   privacy service:
+         A network entity that executes privacy functions before
+         forwarding messages to the next hop.  It is sometimes
+         abbreviated to PS in this document.
+
+   user-level privacy:
+         Privacy for user-inserted information that can be anonymized by
+         the user agent itself.
+
+3.  Semantics of Existing priv-values
+
+   This section provides the semantics of each priv-value defined in
+   RFCs 3323, 3325, and 4244.  The descriptions are taken from the IANA
+   registration.
+
+   Privacy Type  Description                             Reference
+   ------------- ----------------------------------      ----------
+   user          Request that privacy services           [RFC3323]
+                 provide a user-level privacy function
+
+   header        Request that privacy services modify    [RFC3323]
+                 headers that cannot be set arbitrarily
+                 by the user (Contact/Via).
+
+   session       Request that privacy services provide   [RFC3323]
+                 privacy for session media
+
+   none          Privacy services must not perform any   [RFC3323]
+                 privacy function
+
+   critical      Privacy service must perform the        [RFC3323]
+                 specified services or fail the request
+
+   id            Privacy requested for Third-Party       [RFC3325]
+                 Asserted Identity
+
+
+
+
+
+Munakata                      Informational                     [Page 4]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   history       Privacy requested for                   [RFC4244]
+                 History-Info header(s)
+
+4.  Target for Each priv-value
+
+   Tables in this section show the recommended treatment of SIP headers
+   and SDP parameters per priv-value.  SIP headers and SDP parameters
+   not shown in the tables are regarded as non-targets of these priv-
+   values.  Some non-target SIP headers/SDP parameters may carry
+   privacy-sensitive information that may need privacy treatment
+   regardless of the privacy level requested.  This is further described
+   in 5.3.
+
+   The way in which SIP headers and SDP parameters listed here are
+   obscured may depend on the implementation and network policy.  This
+   document does not prevent different variations that may exist based
+   on local policy but tries to provide recommendations for how a
+   privacy service treats SIP headers and SDP parameters.
+
+   Note: The scope of these tables is SIP headers and related parameters
+         specified in RFCs.
+
+4.1.  Target SIP Headers for Each priv-value
+
+   Table 1 below shows a recommended treatment of each SIP header for
+   each priv-value.  Detailed descriptions of the recommended treatment
+   per SIP header are covered in Section 5.
+
+   The "where" column describes the request and response types in which
+   the header needs the treatment to maintain privacy.  Values in this
+   column are:
+
+      R: The header needs the treatment when it appears in a request.
+
+      r: The header needs the treatment when it appears in a response.
+
+   The next five columns show the recommended treatment for each priv-
+   value:
+
+      delete: The header is recommended to be deleted at a privacy
+         service.
+
+      not add: The header is recommended not to be added at a privacy
+         service.
+
+      anonymize: The header is recommended to be anonymized at a privacy
+         service.  How to anonymize the header depends on the header.
+         Details are given in Section 5.
+
+
+
+Munakata                      Informational                     [Page 5]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+      anonymize*: An asterisk indicates that the involvement of a
+         privacy service and treatment of the relevant header depend on
+         the circumstance.  Details are given in Section 5.
+
+   Target headers    where   user     header    session   id   history
+   --------------------------------------------------------------------
+   Call-ID (Note)      R   anonymize    -         -       -      -
+   Call-Info           Rr   delete    not add     -       -      -
+   Contact             R      -      anonymize    -       -      -
+   From                R   anonymize    -         -       -      -
+   History-Info        Rr     -       delete    delete    -    delete
+   In-Reply-To         R    delete      -         -       -      -
+   Organization        Rr   delete    not add     -       -      -
+   P-Asserted-Identity Rr     -       delete      -     delete   -
+   Record-Route        Rr     -      anonymize    -       -      -
+   Referred-By         R   anonymize*   -         -       -      -
+   Reply-To            Rr   delete      -         -       -      -
+   Server              r    delete    not add     -       -      -
+   Subject             R    delete      -         -       -      -
+   User-Agent          R    delete      -         -       -      -
+   Via                 R      -      anonymize    -       -      -
+   Warning             r   anonymize    -         -       -      -
+
+           Table 1: Recommended PS behavior for each SIP header
+
+   Note: Any time a privacy service modifies a Call-ID, it MUST retain
+         the former and modified values as indicated in Section 5.3 in
+         RFC 3323.  It MUST then restore the former value in a Call-ID
+         header and other corresponding headers and parameters (such as
+         In-Reply-To, Replaces, and Target-Dialog) in any messages that
+         are sent using the modified Call-ID to the originating user
+         agent.  It should also modify a Call-ID header and other
+         corresponding headers/parameters (such as Target-Dialog and
+         "replaces" parameter) in any further relevant messages that are
+         sent by the originating user agent.  Refer to Section 5.1.1
+         (Call-ID) for the detailed behavior.
+
+   Identity/Identity-Info, Path, Replaces, Route, Service-Route, and
+   Target-Dialog headers are not targets of these priv-values (and
+   should not be anonymized or modified by a privacy service based on a
+   priv-value in a Privacy header).  Refer to Section 5.3 for details.
+
+4.2.  Target SDP Parameters for Each priv-value
+
+   The recommended PS behaviors for each SDP parameters are simple.  The
+   c, m, o, i, u, e, and p lines in SIP request/response are recommended
+   to be anonymized when user privacy is requested with Privacy:session.
+
+
+
+
+Munakata                      Informational                     [Page 6]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+4.3.  Treatment of priv-value Not Supported by the Privacy Service
+
+   As specified in RFC 3323, if the priv-value of "critical" is present
+   in the Privacy header of a request, and if the privacy service is
+   incapable of performing all of the levels of privacy specified in the
+   Privacy header, it MUST fail the request with a 500 (Server Error)
+   response code as indicated in Section 5 in RFC 3323.
+
+   Since the protection of privacy is important, even if the priv-value
+   "critical" is not present in the Privacy header, the privacy service
+   should fail the request with a 500 response code when it is incapable
+   of performing all of the levels of privacy specified in the Privacy
+   header.
+
+5.  Recommended Treatment of User-Privacy-Sensitive Information
+
+   The following SIP headers and related parameters may concern privacy.
+   This section describes what kind of user-privacy-sensitive
+   information may be included in each SIP header/parameter, and how to
+   maintain privacy for such information at a user agent or a privacy
+   service when the information is indeed privacy-sensitive.
+
+5.1.  Target SIP Headers
+
+   This section describes privacy considerations and recommended
+   treatment for each SIP header that may reveal user-privacy-sensitive
+   information.  This section goes into details about how each header
+   affects privacy, the desired treatment of the value by the user agent
+   and privacy service, and other instructions/additional notes
+   necessary to provide privacy.
+
+5.1.1.  Call-ID
+
+   This field frequently contains an IP address or hostname of a UAC
+   (User Agent Client) appended to the Call-ID value.
+
+   A user agent executing a user-level privacy function on its own
+   SHOULD substitute for the IP address or hostname that is frequently
+   appended to the Call-ID value a suitably long random value (the value
+   used as the 'tag' for the From header of the request might even be
+   reused) as indicated in Section 4.1 in RFC 3323.
+
+   A privacy service MAY anonymize the Call-ID header when the request
+   contains Privacy:user by substituting for the IP address or hostname
+   in the Call-ID a suitably long random value (such as a From tag
+   value) so that it is sufficiently unique as indicated in Section 5.3
+   in RFC 3323.
+
+
+
+
+Munakata                      Informational                     [Page 7]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   Call-ID is essential to dialog matching, so any time a privacy
+   service modifies this field, it MUST retain the former value and
+   restore it in a Call-ID header in any messages that are sent to/by
+   the originating user agent inside the dialog as indicated in Section
+   5.3 in RFC 3323.  A privacy service should be prepared to receive a
+   request outside the dialog containing the value of the Call-ID set by
+   the PS in other SIP headers (e.g., In-Reply-To/Replaces/
+   Target-Dialog), at least while the dialog state is active for the
+   dialog whose Call-ID was modified by that PS.  When such a request is
+   received, the Call-ID value contained in the relevant headers
+   indicated above should be replaced by the retained value.
+
+   Note: This is possible only if the privacy service maintains the
+         state and retains all the information it modified to provide
+         privacy.  Some PSs are known to encrypt information prior to
+         obfuscation in the Via header, etc.  In this case, the PS
+         cannot correlate the modified Call-ID value with the original
+         Call-ID.  Further challenges are imposed when the PS needs to
+         stay on a signaling path to ensure that it receives all the
+         messages targeted towards the caller for which a PS provides
+         privacy, especially when the request is out-of-dialog.
+
+   Refer to the corresponding sections, 5.1.6 (In-Reply-To), 5.3.3
+   (Replaces Header/Parameter), and 5.3.6 (Target-Dialog), for detailed
+   discussion.
+
+5.1.2.  Call-Info
+
+   This field contains additional information about the user.
+
+   A user agent executing a user-level privacy function on its own
+   SHOULD NOT add a Call-Info header as indicated in Section 4.1 in RFC
+   3323.
+
+   A privacy service MUST delete a Call-Info header if one exists when
+   user privacy is requested with Privacy:user as indicated in Section
+   5.3 in RFC 3323.  A privacy service SHOULD NOT add a Call-Info header
+   when user privacy is requested with Privacy:header as indicated in
+   Section 5.1 in RFC 3323.
+
+5.1.3.  Contact
+
+   This field contains a URI used to reach the user agent for mid-dialog
+   requests and possibly out-of-dialog requests, such as REFER
+   [RFC3315].  Since the Contact header is essential for routing further
+   requests to the user agent, it must include a functional URI even
+   when it is anonymized.
+
+
+
+
+Munakata                      Informational                     [Page 8]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   A user agent MUST NOT anonymize a Contact header, unless it can
+   obtain an IP address or contact address that is functional yet has a
+   characteristic of anonymity as indicated in Section 4.1.1.3 in RFC
+   3323.
+
+   Since RFC 3323 was published, there have been proposals that allow
+   UAs to obtain an IP address or contact address with a characteristic
+   of anonymity.
+
+   The mechanisms that are discussed at the time of this writing are
+   Globally Routable User Agent URIs (GRUU) [SIPGRUU], which provides a
+   functional Contact address with a short life span, making it ideal
+   for privacy sensitive calls, and Traversal Using Relays around NAT
+   (TURN) [TURN], through which an IP address of a relay can be obtained
+   for use in a Contact header.
+
+   A privacy service SHOULD anonymize a Contact header by replacing the
+   existing Contact header field value with the URI that dereferences to
+   the privacy service when user privacy is requested with
+   Privacy:header, as indicated in Section 5.1 in RFC 3323.  This is
+   generally done by replacing the IP address or hostname with that of
+   the privacy service.
+
+5.1.4.  From
+
+   This field contains the identity of the user, such as display-name
+   and URI.
+
+   A user agent executing a user-level privacy function on its own
+   SHOULD anonymize a From header using an anonymous display-name and an
+   anonymous URI as indicated in Section 4.1 in RFC 3323.
+
+   A privacy service should anonymize a From header when user privacy is
+   requested with Privacy:user.
+
+   Note: This does not prevent a privacy service from anonymizing the
+         From header based on local policy.
+
+   The anonymous display-name and anonymous URI mentioned in this
+   section use display-name "Anonymous", a URI with "anonymous" in the
+   user portion of the From header, and the hostname value
+   "anonymous.invalid" as indicated in Section 4.1.1.3 in RFC 3323.
+
+   The recommended form of the From header for anonymity is:
+
+   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
+
+
+
+
+
+Munakata                      Informational                     [Page 9]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   The tag value varies from dialog to dialog, but the rest of this
+   header form is recommended as shown.
+
+5.1.5.  History-Info
+
+   History-Info [RFC4244] header URIs to which the request was forwarded
+   or retargeted can reveal general routing information.
+
+   A user agent executing a user-level privacy function on its own
+   SHOULD NOT add a History-Info header as indicated in Section 3.3 in
+   RFC 4244.
+
+   A privacy service SHOULD delete the History-Info headers when user
+   privacy is requested with Privacy:header, Privacy:session, or
+   Privacy:history as indicated in Section 3.3 in RFC 4244.
+
+   The privacy could be also expressed for a specific History-Info entry
+   by inserting "privacy=history" in the History-Info header.  In such a
+   case, a privacy service SHOULD delete the History-Info entry as
+   indicated in Section 4.3.3.1.1 in RFC 4244.
+
+   Refer to [RFC4244] for detailed behavior for dealing with History-
+   Info headers.
+
+5.1.6.  In-Reply-To
+
+   The In-Reply-To header contains a Call-ID of the referenced dialog.
+   The replying user may be identified by the Call-ID in an In-Reply-To
+   header.
+
+   Alice > INV(Call-ID:C1) > Bob
+   Bob   > INV(In-Reply-To:C1) > Alice
+
+   In this case, unless the In-Reply-To header is deleted, Alice might
+   notice that the replying user is Bob because Alice's UA knows that
+   the Call-ID relates to Bob.
+
+   A user agent executing a user-level privacy function on its own
+   should not add an In-Reply-To header as implied in Section 4.1 in RFC
+   3323.
+
+   A privacy service MUST delete the In-Reply-To header when user
+   privacy is requested with Privacy:user as indicated in Section 5.3 in
+   RFC 3323.
+
+   In addition, since an In-Reply-To header contains the Call-ID of the
+   dialog to which it is replying, special attention is required, as
+   described in Section 5.1.1 (Call-ID), regardless of the priv-value or
+
+
+
+Munakata                      Informational                    [Page 10]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   presence of a Privacy header.  Once a privacy service modifies a
+   Call-ID in the request, a privacy service should restore the former
+   value in an In-Reply-To header, if present in the INVITE request
+   replying to the original request, as long as the privacy service
+   maintains the dialog state.
+
+   Example:
+   Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
+   Bob   > INV(In-Reply-To:C2, Privacy:none) > PS >
+           INV(In-Reply-To:C1) > Alice
+
+   Note: This is possible only if the privacy service maintains the
+         state and retains all the information that it modified to
+         provide privacy even after the dialog has been terminated,
+         which is unlikely.  Call-back is difficult to achieve when a
+         privacy service is involved in forming the dialog to be
+         referenced.
+
+5.1.7.  Organization
+
+   This field contains additional information about the user.
+
+   A user agent executing a user-level privacy function on its own
+   should not add an Organization header as implied in Section 4.1 in
+   RFC 3323.
+
+   A privacy service MUST delete the Organization header if one exists
+   when user privacy is requested with Privacy:user as indicated in
+   Section 5.3 in RFC 3323.  A privacy service SHOULD NOT add an
+   Organization header when user privacy is requested with Privacy:
+   header as indicated in Section 5.1 in RFC 3323.
+
+5.1.8.  P-Asserted-Identity
+
+   This header contains a network-verified and network-asserted identity
+   of the user sending a SIP message.
+
+   A privacy service MUST delete the P-Asserted-Identity headers when
+   user privacy is requested with Privacy:id as indicated in Section 7
+   in RFC 3325 and should delete the P-Asserted-Identity headers when
+   user privacy is requested with Privacy:header before it forwards the
+   message to an entity that is not trusted.
+
+   It is recommended for a privacy service to remove the P-Asserted-
+   Identity header if user privacy is requested with Privacy:id or
+   Privacy:header even when forwarding to a trusted entity, unless it
+   can be confident that the message will not be routed to an untrusted
+   entity without going through another privacy service.
+
+
+
+Munakata                      Informational                    [Page 11]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+5.1.9.  Record-Route
+
+   This field may reveal information about the administrative domain of
+   the user.
+
+   In order to hide Record-Route headers while keeping routability to
+   the sender, privacy services can execute a practice referred to as
+   "stripping".  Stripping means removing all the Record-Route headers
+   that have been added to the request prior to its arrival at the
+   privacy service and then adding a single Record-Route header
+   representing itself.  In this case, the privacy service needs to
+   retain the removed headers and restore them in a response.
+
+   Alternatively, privacy services can remove the Record-Route headers
+   and encrypt them into a single Record-Route header field.  In this
+   case, the privacy service needs to decrypt the header and restore the
+   former values in a response.
+
+   A privacy service SHOULD strip or encrypt any Record-Route headers
+   that have been added to a message before it reaches the privacy
+   service when user privacy is requested with Privacy:header as
+   indicated in Section 5.1 in RFC 3323.
+
+   As in the case of a Call-ID, if a privacy service modifies the
+   Record-Route headers, it MUST be able to restore Route headers with
+   retained values as indicated in Section 5.1 in RFC 3323.  Some
+   examples where the restoration of the Route headers is necessary and
+   unnecessary are given below.
+
+   When a UAC (Alice) requires privacy for a request, a privacy service
+   does not have to restore the Route headers in the subsequent request
+   (see Example 1).
+
+   On the other hand, when a UAS (User Agent Server) (Bob) requires
+   privacy for a response, a privacy service has to restore the Route
+   headers in the subsequent request (see Example 2).
+
+   Example 1:
+   Restoration of Route header is UNNECESSARY when UAC requires privacy
+   Alice > INV(Privacy:header) > P1 >
+           INV(Record-Route:P1, Privacy:header) > PS >
+           INV(Record-Route:PS) > P2 >
+           INV(Record-Route:P2,PS) > Bob
+   Bob   > 200(Record-Route:P2,PS) > P2 > PS >
+           200(Record-Route:P2,PS,P1) > P1 > Alice
+   Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 >
+           re-INV(Route:P2,PS, Privacy:header) > PS >
+           re-INV(Route:P2) > P2 > re-INV > Bob
+
+
+
+Munakata                      Informational                    [Page 12]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+ Alice             P1                PS                P2            Bob
+ |                 |                 |                 |               |
+ | INV Priv        |INV Priv RR:P1   | INV RR:PS       | INV RR:P2,PS  |
+ |---------------->|---------------->|---------------->|-------------->|
+ |                 |                 |                 |               |
+ | 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS    | 200 RR:P2,PS  |
+ |<----------------|<----------------|<----------------|<--------------|
+ |                 |                 |                 |               |
+ | INV R:P2,PS,P1  | INV R:P2,PS     | INV R:P2        | INV           |
+ |---------------->|---------------->|---------------->|-------------->|
+ |                 |                 |                 |               |
+
+     Figure 1: Example when restoration of Route header is UNNECESSARY
+
+   Example 2:
+   Restoration of Route header is NECESSARY when UAS requires privacy
+   Alice > INV > P1 > INV(Record-Route:P1) > P2 >
+           INV(Record-Route:P2,P1) > Bob
+   Bob   > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' >
+           200(Record-Route:PS',P1) > P1 > Alice
+   Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' >
+           re-INV(Route:P2) > P2 > Bob
+
+ Alice           P1                PS'               P2              Bob
+ |               |                 |                 |                 |
+ | INV           |INV RR:P1        |                 | INV RR:P2,P1    |
+ |-------------->|---------------------------------->|---------------->|
+ |               |                 |                 |                 |
+ | 200 RR:PS',P1 | 200 RR:PS',P1   |200 Priv RR:P2,P1|200 Priv RR:P2,P1|
+ |<--------------|<----------------|<----------------|<----------------|
+ |               |                 |                 |                 |
+ | INV R:PS',P1  | INV R:PS'       | INV R:P2        | INV             |
+ |-------------->|---------------->|---------------->|---------------->|
+ |               |                 | (Restored)      |                 |
+
+     Figure 2: Example when restoration of Route header is NECESSARY
+
+   Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record-
+         Route header, and R means Route header.
+
+5.1.10.  Referred-By
+
+   The Referred-By [RFC3892] header carries a SIP URI representing the
+   identity of the referrer.
+
+   The Referred-By header is an anonymization target when the REFER
+   request with the Referred-By header is sent by the user (referrer)
+   whose privacy is requested to be processed in the privacy service.
+
+
+
+Munakata                      Informational                    [Page 13]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   A user agent that constructs REFER requests executing a user-level
+   privacy function on its own should anonymize a Referred-By header by
+   using an anonymous URI.
+
+   A privacy service should anonymize a Referred-By header in a REFER
+   request by using an anonymous URI when user privacy is requested with
+   Privacy:user.
+
+   On the other hand, the Referred-By header is not an anonymization
+   target when it appears in a request other than REFER (e.g., INVITE)
+   because the URI in the Referred-By header does not represent the
+   sender of the request.
+
+   Example 1:
+   Referrer requests no privacy and referee requests privacy
+   Alice > REF(Referred-By:Alice) > Bob
+   Bob   > INV(Referred-By:Alice, Privacy:user) > PS >
+           INV(Referred-By:Alice) > Carol
+
+   Example 2:
+   Referrer requests privacy and referee requests privacy
+   Alice > REF(Referred-By:Alice, Privacy:user) > PS >
+           REF(Referred-By:X) > Bob
+   Bob   > INV(Referred-By:X, Privacy:user) > PS >
+           INV(Referred-By:X) > Carol
+
+5.1.11.  Reply-To
+
+   This field contains a URI that can be used to reach the user on
+   subsequent call-backs.
+
+   A user agent executing a user-level privacy function on its own
+   should not add a Reply-To header in the message as implied in Section
+   4.1 in RFC 3323.
+
+   A privacy service MUST delete a Reply-To header when user privacy is
+   requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
+
+5.1.12.  Server
+
+   This field contains information about the software used by the UAS to
+   handle the request.
+
+   A user agent executing a user-level privacy function on its own
+   should not add a Server header in the response as implied in Section
+   4.1 in RFC 3323.
+
+
+
+
+
+Munakata                      Informational                    [Page 14]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   A privacy service must delete a Server header in a response when user
+   privacy is requested with Privacy:user.  A privacy service SHOULD NOT
+   add a Server header in a response when user privacy is requested with
+   Privacy:header as indicated in Section 5.1 in RFC 3323.
+
+5.1.13.  Subject
+
+   This field contains free-form text about the subject of the call.  It
+   may include text describing something about the user.
+
+   A user agent executing a user-level privacy function on its own
+   should not include any information identifying the caller in a
+   Subject header.
+
+   A privacy service MUST delete a Subject header when user privacy is
+   requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
+
+5.1.14.  User-Agent
+
+   This field contains the UAC's information.
+
+   A user agent executing a user-level privacy function on its own
+   should not add a User-Agent header as implied in Section 4.1 in RFC
+   3323.
+
+   A privacy service MUST delete a User-Agent header when user privacy
+   is requested with Privacy:user as indicated in Section 5.3 in RFC
+   3323.
+
+5.1.15.  Via
+
+   The bottommost Via header added by a user agent contains the IP
+   address and port or hostname that are used to reach the user agent
+   for responses.  Via headers added by proxies may reveal information
+   about the administrative domain of the user.
+
+   A user agent MUST NOT anonymize a Via header as indicated in Section
+   4.1.1.3 in RFC 3323, unless it can obtain an IP address that is
+   functional yet has a characteristic of anonymity.  This may be
+   possible by obtaining an IP address specifically for this purpose
+   either from the service provider or through features such as TURN.
+
+   A privacy service SHOULD strip or encrypt any Via headers that have
+   been added prior to reaching the privacy service when user privacy is
+   requested with Privacy:header as indicated in Section 5.1 in RFC
+   3323.  Refer to Section 5.1.9 (Record-Route) for details of stripping
+   and encryption.
+
+
+
+
+Munakata                      Informational                    [Page 15]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   A privacy service MUST restore the original values of Via headers
+   when handling a response in order to route the response to the
+   originator as indicated in Section 5.1 in RFC 3323.
+
+   No Via stripping is required when handling responses.
+
+5.1.16.  Warning
+
+   This field may contain the hostname of the UAS.
+
+   A user agent executing a user-level privacy function on its own
+   should not include the hostname representing its identity in a
+   Warning header.
+
+   A privacy service should anonymize a Warning header by deleting the
+   hostname portion (if it represents a UAS's identity) from the header
+   when user privacy is requested with Privacy:user.
+
+5.2.  Target SDP Parameters
+
+   This section describes privacy considerations for each SDP [RFC4566]
+   parameter that may reveal information about the user.
+
+   When privacy functions for user-inserted information are requested to
+   be executed at a privacy service, user agents MUST NOT encrypt SDP
+   bodies in messages as indicated in Section 4.2 in RFC 3323.
+
+5.2.1.  c/m Lines
+
+   The c and m lines in the SDP body convey the IP address and port for
+   receiving media.
+
+   A user agent must not anonymize the IP address and port in the c and
+   m lines, unless it can obtain an IP address that is functional yet
+   has a characteristic of anonymity as implied in Section 4.1.1.3 in
+   RFC 3323.  This may be possible by obtaining an IP address
+   specifically for this purpose either from the service provider or
+   through features such as TURN.
+
+   A privacy service must anonymize the IP address and port in c and m
+   lines using a functional anonymous IP address and port when user
+   privacy is requested with Privacy:session.  This is generally done by
+   replacing the IP address and port present in the SDP with that of a
+   relay server.
+
+
+
+
+
+
+
+Munakata                      Informational                    [Page 16]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+5.2.2.  o Line
+
+   The username and IP address in this parameter may reveal information
+   about the user.
+
+   A user agent may anonymize the username in an o line by setting
+   username to "-" and anonymize the IP address in the o line by
+   replacing it with a value so that it is sufficiently unique.
+
+   A privacy service must anonymize the username and IP address in the o
+   line by setting the username to "-" and replacing the IP address with
+   a value so that it is sufficiently unique when user privacy is
+   requested with Privacy:session.
+
+5.2.3.  i/u/e/p Lines
+
+   These lines may contain information about the user.
+
+   A user agent executing a session-level privacy function on its own
+   should not include user's information in the i, u, e, and p lines.
+
+   A privacy service should modify the i, u, e, and p lines to delete
+   the user's identity information when user privacy is requested with
+   Privacy:session.
+
+5.3.  Considerations for Non-Target SIP Headers/Parameters
+
+5.3.1.  Identity/Identity-Info
+
+   The Identity [RFC4474] header field contains a signature used for
+   validating the identity.  The Identity-Info header field contains a
+   reference to the certificate of the signer of Identity headers.  An
+   Identity-Info header may reveal information about the administrative
+   domain of the user.
+
+   The signature in an Identity header provides integrity protection
+   over the From, To, Call-ID, Cseq, Date, and Contact headers and over
+   the message body.  The integrity protection is violated if a privacy
+   service modifies these headers and/or the message body for the
+   purpose of user privacy protection.
+
+   Once those integrity-protected headers (such as From and Call-ID) are
+   modified, the Identity/Identity-Info header fields are not valid any
+   more.  Thus, a privacy service acting on a request for Privacy:user,
+   Privacy:header, or Privacy:session can invalidate integrity
+   protection provided by an upstream authentication service that has
+   inserted Identity/Identity-Info header fields.  The use of such a
+   privacy service should be avoided if integrity protect needs to be
+
+
+
+Munakata                      Informational                    [Page 17]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   retained.  Otherwise, if the privacy service invalidates the
+   integrity protection, it should remove the Identity/Identity-Info
+   header fields.
+
+   An authentication service downstream of the privacy service may add
+   Identity/Identity-Info header fields if the domain name of the From
+   header field URI has not been anonymized (e.g.,
+   'sip:anonymous@example.com'), which makes it possible for the service
+   to authenticate the UAC.  This authenticated yet anonymous From
+   header means "this is a known user in my domain that I have
+   authenticated, but I am keeping its identity private" as indicated in
+   Section 12 in RFC 4474.
+
+   The desired deployment will have a privacy service located before or
+   co-located with the identity service; thus, integrity and privacy can
+   both be provided seamlessly.
+
+5.3.2.  Path
+
+   This field may contain information about the administrative domain
+   and/or the visited domain of the user agent.  However, the Path
+   header is not the target of any priv-values.
+
+   Given that the Path header [RFC3327] only appears in REGISTER
+   requests/responses and is essential for a call to reach the
+   registered UA in the visited domain, it serves no purpose to withhold
+   or hide the information contained in the Path header; rather, it is
+   harmful.
+
+   The only reason privacy may be considered desirable is if the visited
+   domain wants to withhold its topology from the home domain of the
+   user.  In doing so, the domain withholding the topology needs to
+   ensure that it provides sufficient information so that the home
+   domain can route the call to the visited domain, thus reaching the
+   UA.
+
+   However, anonymization of network-privacy-sensitive information is
+   out of scope.
+
+5.3.3.  Replaces Header/Parameter
+
+   The Replaces [RFC3891] header and the "replaces" parameter contain
+   identifiers of a dialog to be replaced, which are composed of Call-
+   ID, local tag, and remote tag.
+
+
+
+
+
+
+
+Munakata                      Informational                    [Page 18]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   The sender of the INVITE with a Replaces header is usually not the
+   originating user agent or terminating user agent of the target dialog
+   to be replaced.  Therefore, the Call-ID within the Replaces header is
+   unlikely to be generated by the sender, and thus this header is
+   outside the anonymization target per priv-value.
+
+   The "replaces" parameter, which appears in a Refer-To header in a
+   REFER request, is not the target of any particular priv-values
+   either.  As described in Section 5.1.1 (Call-ID), regardless of the
+   priv-value or the presence of a Privacy header, once a privacy
+   service modifies a Call-ID in the request, it should monitor headers
+   that may contain Call-ID and restore the portion of the value
+   representing the modified Call-ID to the original Call-ID value in a
+   Replaces header received.
+
+   The main challenge for this to function properly is that a privacy
+   service has to be on a signaling path to the originator for every
+   dialog.  This is generally not possible and results in REFER requests
+   not functioning at all times.  This is a trade-off that is
+   anticipated when privacy is imposed.
+
+   The privacy requirements mentioned in Section 5.1.1 will cause the
+   Replaces header and "replaces" parameter to contain values that will
+   fail the resulting dialog establishment in some situations.  This
+   loss of functionality is allowed and/or intended as illustrated above
+   (i.e., it is not the responsibility of a privacy service to ensure
+   that these features always work).
+
+   The functionality of the Replaces header/parameter when anonymized
+   depends on the circumstances in which it is used.  REFER may work or
+   may not work depending on the following three criteria.
+
+   1. Who generated the Call-ID.
+   2. Where the privacy service is on the signaling path.
+   3. Who initiates the REFER with the "replaces" parameter.
+
+   A few examples that explore when the Replaces header/parameter works
+   or fails are given below.
+
+   Example 1:
+   Transfer initiated by the originator, PS added for first INV and REF
+   Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
+   Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
+           REF(Refer-To:Bob?Replaces=C2) > Carol
+   Carol > INV(Replaces:C2) > Bob (SUCCEED)
+
+
+
+
+
+
+Munakata                      Informational                    [Page 19]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   Example 2:
+   Transfer initiated by the originator, PS added only for first INV
+   Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
+   Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
+   Carol > INV(Replaces:C1) > Bob (FAIL)
+
+   Note: Example 2 would succeed if the same PS (that modifies the Call-
+         ID in the INVITE from Alice) is also added for REFER and
+         modifies the value in the "replaces" parameter from C1 to C2
+         even if there is no Privacy header in the REFER.
+
+   Example 3:
+   Transfer initiated by the originator, PS added only for REF
+   Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
+   Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
+           REF(Refer-To:Bob?Replaces=C1) > Carol
+   Carol > INV(Replaces:C1, Privacy:user) > PS' >
+           INV(Replaces:C1) > Bob (SUCCEED)
+
+   Example 4:
+   Transfer initiated by the terminating party, PS added for both INV
+   Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
+   Bob   > REF(Refer-To:Alice?Replaces=C2) > Carol
+   Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED)
+
+   Note: Example 4 succeeds because the same PS (that modifies the Call-
+         ID in the INVITE from Alice) checks the incoming requests and
+         modifies the value in a Replaces header in the INVITE from
+         Carol to the former value of Call-ID (C1).
+
+   Example 5:
+   Hold, PS added only for first INV
+   Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
+   Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
+   Music-Server > INV(Replaces:C1) > Bob (FAIL)
+
+   Note: Example 5 would succeed if the same PS (that modifies the Call-
+         ID in the INVITE from Alice) is added for the INVITE from the
+         Music-Server and modifies the value in a Replaces header from
+         C1 to C2.
+
+   As the above examples show, in some scenarios, information carried in
+   the Replaces header/parameter would result in failure of the REFER.
+   This will not happen if the Call-ID is not modified at a privacy
+   service.
+
+
+
+
+
+
+Munakata                      Informational                    [Page 20]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+5.3.4.  Route
+
+   This field may contain information about the administrative domain of
+   the user agent, but the Route header is not the target of any priv-
+   values.
+
+   Route headers appear only in SIP requests to force routing through
+   the listed set of proxies.  If a privacy service anonymizes the Route
+   header, the routing does not function.  Furthermore, there is no risk
+   in revealing the information in the Route headers to further network
+   entities, including the terminating user agent, because a proxy
+   removes the value from the Route header when it replaces the value in
+   the Request-URI as defined in RFC 3261.
+
+   A privacy service that modifies Record-Route headers may need to
+   restore the values in Route headers as necessary.  As indicated in
+   Section 5.1 in RFC 3323, if a privacy service modifies the Record-
+   Route headers, it MUST be able to restore Route headers with retained
+   values.  Please refer to Section 5.1.9 (Record-Route) for further
+   detail and examples.
+
+5.3.5.  Service-Route
+
+   Service-Route headers [RFC3608] appear only in 200 OK responses to
+   REGISTER requests and contain information about the registrar.  The
+   purpose of the privacy mechanism defined in RFC 3323 is to secure the
+   user's privacy, so the case where a registrar sets a Privacy header
+   is not considered here.  Therefore, the Service-Route header is not
+   the target of any priv-values.
+
+5.3.6.  Target-Dialog
+
+   The Target-Dialog [RFC4538] header faces exactly the same issues as
+   seen for the Replaces header.  Please refer to Section 5.3.3
+   (Replaces Header/Parameter) for why this is not a target for any
+   particular priv-values and how a privacy service still needs to
+   evaluate and modify the value contained, even if no privacy is
+   requested.
+
+6.  Security Considerations
+
+   This guideline document adds no new security considerations to those
+   discussed in [RFC3323], [RFC3325], and [RFC4244].
+
+
+
+
+
+
+
+
+Munakata                      Informational                    [Page 21]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+7.  Acknowledgements
+
+   The authors would like to thank John Elwell, Jon Peterson, Jonathan
+   Rosenberg, Mary Barnes, Paul Kyzivat, and Roland Jesske for their
+   reviews and comments.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  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.
+
+   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
+              Initiation Protocol (SIP)", RFC 3323, November 2002.
+
+   [RFC3325]  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.
+
+   [RFC4244]  Barnes, M., Ed., "An Extension to the Session Initiation
+              Protocol (SIP) for Request History Information", RFC 4244,
+              November 2005.
+
+8.2.  Informative References
+
+   [TURN]     Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
+              Relays around NAT (TURN): Relay Extensions to Session
+              Traversal Utilities for NAT (STUN)", Work in Progress,
+              July 2008.
+
+   [SIPGRUU]  Rosenberg, J., "Obtaining and Using Globally Routable User
+              Agent URIs (GRUUs) in the Session Initiation Protocol
+              (SIP)", RFC 5627, October 2009.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
+              (SIP) Extension Header Field for Registering Non-Adjacent
+              Contacts", RFC 3327, December 2002.
+
+
+
+Munakata                      Informational                    [Page 22]
+
+RFC 5379                 SIP Privacy Guidelines            February 2010
+
+
+   [RFC3608]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
+              (SIP) Extension Header Field for Service Route Discovery
+              During Registration", RFC 3608, October 2003.
+
+   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
+              Protocol (SIP) "Replaces" Header", RFC 3891, September
+              2004.
+
+   [RFC3892]  Sparks, R., "The Session Initiation Protocol (SIP)
+              Referred-By Mechanism", RFC 3892, September 2004.
+
+   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
+              Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+   [RFC4538]  Rosenberg, J., "Request Authorization through Dialog
+              Identification in the Session Initiation Protocol (SIP)",
+              RFC 4538, June 2006.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+Authors' Addresses
+
+   Mayumi Munakata
+   NTT Corporation
+
+   Phone: +81 422 36 7502
+   EMail: munakata.mayumi@lab.ntt.co.jp
+
+
+   Shida Schubert
+   NTT Corporation
+
+   EMail: shida@ntt-at.com
+
+
+   Takumi Ohba
+   NTT Corporation
+   9-11, Midori-cho 3-Chome
+   Musashino-shi, Tokyo  180-8585
+   Japan
+
+   Phone: +81 422 59 7748
+   EMail: ohba.takumi@lab.ntt.co.jp
+
+
+
+
+
+
+Munakata                      Informational                    [Page 23]
+