There have been concerns expressed in IETF that 3GPP is abusing IETF
protocols and that we should do something about it.  The 3GPP usage of
SIP certainly appears to be inconsistent with that posited by the IETF.
   
We may wish to consider what approach, if any, should be
pursued.

This text addresses the following:
   
      * General issues with the 3GPP approach
      * Underlying assumptions by 3GPP that contribute to the inconsistency.
      * Specific design issues relating to SIP that create problems.
      * Options that we may wish to consider.
   
General issues with 3GPP Approach:
   
1) Conformance to syntax, but not philosophy or rationale of
   IETF specifications.  The packets look right "on the wire", but
   the overall systems operate very differently.
   
   2) An IETF SIP client will not work on the 3GPP network.
   
   3) 3GPP clients can interoperate only in a limited fashion with IETF
      systems.
   
   4) The 3GPP model does not support IETF goals of openess and
      transparency.
   
There are several underlying assumptions made by 3GPP that seem
to differ from the IETF approach and that drive much of the
disagreeable behavior.
   
1) The 3GPP network is closed:
   
Only 3GPP-specific phones may be used. The phones and the network
are designed such that the phones MUST talk through the 3GPP
"proxy" network. There MAY be gateways to talk to the
outside world.
   
2) The 3GPP network is "trusted":
   
As they explicitly trust all network elements, protocol provisions
intended by the IETF to protect the user from aberrant network elements
represent unecessary overhead and may be ignored.
   
3) 3GPP clients may use external or "Internet" SIP proxy-based
services only by the explicit consent of the operator:
   
An explicit configuration change is required to use any such service. 
Operational issues dictate that this sort of change will either be
forbidden or expensive.  This effectively prevents the 3GPP user from
using most of the services that SIP was designed to enable.  Services
that operate like traditional PSTN "service nodes" and are directly
addressed (rather than traversed as proxies) may be usable subject to
the constraints imposed by the rest of the 3GPP architecture, including
#1 above and #4 below.

4) Support for end-to-end message protection using S/MIME is
not required by 3GPP:
   
This mechanism is required by RFC 3261 but appears to be specifically
precluded by 3GPP.  Certainly, 3GPP Release 5 will not address it, and
the operation of the 3GPP "proxy" network in release 5 prevents its use. 
Millions of non-upgradeable phones will be issued under release 5,
assuring incompatibility of security provisions for years to come.
   
5) The "network" must be protected from the users: 
   
3GPP designs to protect "the network" from the users rather than
protecting the users from hostile network elements.  Protection
techniques rely heavily on both security-through-obscurity (topology
hiding, etc.) and filtering.



1) The P-CSCF may send a BYE on behalf of the UA, generally because
   the P-CSCF has been notified by the radio layer that the UA has
   lost contact.  Of course, it doesn't have the credentials to
   authenticate the BYE, so many UAs will consider this as a forged
   message. The side effect is that 3GPP UAs become vulnerable to DoS
   attacks using forged BYEs.


Reference:


5.2.8.1.2	Release of an existing session

Upon receipt of an indication that the radio interface resources are
no longer available for a served user, for whom one or more ongoing
session exists, the P-CSCF shall release each of the related dialogs
by applying the following steps:

1) if the P-CSCF serves the calling user of a session it shall
generate a BYE request based on the information saved for the related
dialog, including:

  - a Request-URI, set to the stored Contact header provided by
    the called user;

  - a To header, set to the To header value as received in the
    200 (OK) response for the initial INVITE request;

  - a From header, set to the From header value as received in
    the initial INVITE request;

  - a Call-ID header, set to the Call-Id header value as received in
    the initial INVITE request;

  - a CSeq header, set to the CSeq value that was stored for the
    direction from the calling to the called user, incremented by one;

  - a Route header, set to the routeing information towards the called
    user as stored for the dialog;

  - further headers, based on local policy or the requested session
    release reason.

2) If the P-CSCF serves the called user of a session it shall generate a
BYE request 
based on the information saved for the related dialog, including:

  - a Request-URI, set to the stored Contact header provided by the
    calling user;

  - a To header, set to the From header value as received in the
    initial INVITE request;

  - a From header, set to the To header value as received in the 200
    (OK) response for the initial INVITE request;

  - a Call-ID header, set to the Call-Id header value as received in
    the initial INVITE request;

  - a CSeq header, set to the CSeq value that was stored for the
    direction from the called to the calling user, incremented by one
    $(H i(Bf no CSeq value was stored for that session it shall
    generate and apply a random number within the valid range for
    CSeqs;

  - a Route header, set to the routeing information towards the
    calling user as stored for the dialog;

  - further headers, based on local policy or the requested session
    release reason.

3) send the so generated BYE request towards the indicated user.

4) upon receipt of the 2xx responses for the BYE request, shall delete
all information 
related to the dialog and the related multimedia session.



------------------------------------------------------------------------
------
Issue:

2) The P-CSCF strips away Route, Record-Route, Via, Path, and
   P-Service-Route headers before passing messages on to the UA. It
   then reinserts them properly on messages in the other direction,
   and may also strip out Route headers inserted by the UA. This
   breaks end-to-end protection and prevents the UA from accessing
   external proxy services. It also prevents the UA from knowing about
   any proxies that may have piggybacked on its registration using the
   Path mechanism, which is a serious violation of the openness
   principle.


Reference:

5.2.2	Registration

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF
shall:

1) insert a Path header in the request including an entry containing: 

  -  the SIP URL identifying the P-CSCF;

  - an indication that requests routed in this direction of the path
    (i.e. from the S-CSCF to the P-CSCF) shall be treated as for the
    mobile-terminating case. This indication may e.g. be in a Path
    header parameter, a character string in the user part or be a port
    number;

2) insert a Supported and a Require header both containing the option
tag "path";

<dw NOTE: This appears to violate the Supported/Require model in Path
RFC </dw

3) for the initial REGISTER request for a public user identity create
a new, globally aunique value for icid, save it locally and insert it
into the icid parameter of the P-Charging-Vector header (see subclause
7.2.5). Also include the gprs-charging-info parameter in the
P-Charging-Vector header (see subclause 5.2.7.4);

4) insert the parameter "integrity-protected" (described in subclause
7.2A.2) with a value $(Cye(Bs$(D i(Bnto the Authorization header
field
in case the REGISTER request was received integrity protected,
otherwise insert the parameter with the value $(Cno$(D;

(B5) insert a P-Visited-Network-ID header field, with the value of a
pre-provisioned string that identifies the visited network at the home
network; and

6) determine the I-CSCF of the home network and forward the request to
that I-CSCF.  When the P-CSCF receives a 200 (OK) response to a
REGISTER request, the P-CSCF shall check the value of the Expires
header field and/or Expires parameter in the Contact header. When the
value of the Expires header field and/or expires parameter in the
Contact header is different than zero, then the P-CSCF shall:

====HERE IT IS!!!====

1) save the list of P-Service-Route headers preserving the order. This
list shall be stored during the entire registration period of the
respective public user identity. This list shall be used to preload
the routeing information into the initial requests originated by the
UE. If this registration is a reregistration, the P-CSCF shall replace
the already existing list of P-Service-Route headers with the new
list;

2) associate the P-Service-Route header information with the registered
public user 
identity;

3) remove any Path and P-Service-Route headers from the 200 (OK)
response before forwarding the response to the UE;

4) store the public user identities found in the P-Associated-URI
header value, as those that are authorized to be used by the UE;

5) store the default public user identity for use with procedures for
the P-Asserted-Identity. The default public user identity is
specifically indicated in the Associated-URI header values.

Editor's note: The exact mechanism for indicating this value is for
further discussion.  When the P-CSCF receives a 200 (OK) response to a
REGISTER request, the P-CSCF shall store the values received in the
P-Charging-Function-Addresses header.  When the P-CSCF receives a 401
(Unauthorized) response to a REGISTER request, the P-CSCF shall remove
and store the CK and IK values contained in the 401 (Unauthorized)
response.  The 401 Unauthorized response shall be forwarded to the UE
if and only if the CK and IK have been removed.

NOTE: The P-CSCF will maintain two Route lists. The first Route list -
created during the registration procedure - is used only to pre-load
the routeing information into the initial INVITE request that
originated at the UE. This list is valid during the entire
registration of the respective public user identity. The second Route
list - constructed from the Record Route headers in the initial INVITE
and associated response - is used during the duration of the
call. Once the call is terminated, the second Route list is discarded.


5.2.6.3	Requests initiated by the UE

When the P-CSCF receives an initial request for a dialog or a request
for a standalone transaction, and the request contains as
P-Asserted-Identity header that matches one of the registered public
user identities, the P-CSCF shall identify the initiator of the
request by that public user identity.

When the P-CSCF receives an initial request for a dialog or a request
for a standalone transaction, and the request contains as
P-Asserted-Identity header that does not match one of the registered
public user identities, or does not contain a P-Asserted-Identity
header, the P-CSCF shall identify the initiator of the request by a
default public user identity.

NOTE: The contents of the From header do not form any part of this
decision process.


====HERE IT IS!!!====

When the P-CSCF receives from the UE an initial request for a dialog,
and a P-Service-Route header list exists for the initiator of the
request, the P-CSCF shall:

  - remove any Route header from the request;

  - select the list of Route headers that was created during the
    registration or reregistration of the respective public user
    identity utilizing the P-Service-Route mechanism;

  - pre-load the list of Route headers to the request;

  - create a Record-Route header containing its own SIP URL;

  - insert a P-Asserted-Identity header with a value representing the
    initiator of the request;

  - create a new, globally unique value for the icid parameter and
    insert it into the P-Charging-Vector header; and

  - forward the request based on the topmost Route header.  When the
    P-CSCF receives a 1xx or 2xx response to the above request, the
    P-CSCF shall:

  - store the values received in the P-Charging-Function-Addresses
    header;

  - remove the list of Record-Route headers from the received
    response;

  - create a new list of stored Route headers, with the newly received
    list of Record-Route headers. The Contact header received in the
    response shall not be appended to the bottom of the stored list of
    Route headers;

 - store the dialog ID and associate it with the private user identity
   and public user identity involved in the session; and

  - save the Contact header received in the response in order to
    release the dialog if needed.  When the P-CSCF receives any other
    response to the above request, the P-CSCF shall:

  - remove any list of Record-Route headers, even though not allowed,
    from the received response and forward it to the UE.  When the
    P-CSCF receives from the UE a refresh request for a dialog, the
    P-CSCF shall:

  - remove any Route header from the request;

  - select the list of Route headers that was created during the
    exchange of the initial request and its associated response;

  - pre-load the list of Route headers to the request;

  - create a Record-Route header containing its own SIP URL;

  - verify if the request relates to a dialog in which the originator
    of the request is involved. If the request does not relates to a
    dialog in which the originator is involved, then a 403 response
    shall be sent back to the originator; and

  - forward the request based on the topmost Route header.  When the
    P-CSCF receives a 1xx or 2xx response to the above request, the
    P-CSCF shall:

  - remove the list of Record-Route headers from the received response;

  - overwrite any existing list of stored Route headers, or create a
    new list of stored Route headers, with the newly received list of
    Record-Route headers. The Contact header received in the response
    shall not be appended to the bottom of the stored list of Route
    headers; and

  - save the Contact header received in the response in order to
    release the dialog if needed.  

When the P-CSCF receives any other response to the above request, the
P-CSCF shall:

  - remove any list of Record-Route headers, even though not allowed,
    from the received response and forward it to the UE.  When the
    P-CSCF receives from the UE the request for a standalone
    transaction, and a P-Service-Route header list exists for the
    initiator of the request, the P-CSCF shall:

  - remove any Route header from the request;

  - select the list of Route headers that was created during the
    registration or reregistration of the respective public user
    identity utilizing the P-Service-Route mechanism;- pre-load the
    list of Route headers to the request;

  - insert a P-Asserted-Identity header with a value representing the
    initiator of the request;

  - create a new, globally unique value for the icid parameter and
    insert it into the P-Charging-Vector header; and

  - forward the request based on the topmost Route header.  When the
    P-CSCF receives any response to the above request, the P-CSCF
    shall:

  - store the values received in the P-Charging-Function-Addresses
    header; and

  - remove any list of Record-Route headers, even though not allowed,
    from the received response and forward it to the UE.

When the P-CSCF receives from the UE subsequent requests other than a
refreshing request that pertains to an existing dialog, the P-CSCF
shall:

  - select the list of Route headers that was created during the
    exchange of the initial request and associated response for this
    call;

  - pre-load the list of Route headers to the request;

  - verify if the request relates to a dialog in which the originator
    of the request is involved. If the request does not relate to a
    dialog in which the originator is involved, then a 403 response
    shall be sent back to the originator; and

  - forward the request based on the topmost Route header.  When the
    P-CSCF receives any response to the above request, the P-CSCF
    shall:

  - verify if the request relates to a dialog in which the originator
    of the request is involved.. If the request does not relates to a
    dialog in which the originator is involved, then a 403 response
    shall be sent back to the originator; and

  - remove any list of Record-Route headers, valid or not, from the
    received response and forward it to the UE.

When the P-CSCF receives from the UE an initial request for a dialog,
a refresh request for a dialog, or the request of a standalone
transaction, and a P-Service-Route header list does not exist for the
initiator of the request, the P-CSCF shall:

  - send a 403 Forbidden response back to the UE containing a warning
    header.

  Editor's Note: how to find out whether the user has a valid
  registration in the P-CSCF is FFS.

  Editor's Note: The correct value for the warning code is yet to be
  assigned by IANA.

When the P-CSCF receives from the UE the request for an unknown
method, and a P-Service-Route header list exists for the initiator of
the request, the P-CSCF shall:

  - select the list of Route headers that was created during the
    registration or reregistration of the respective public user
    identity utilizing the P-Service-Route mechanism;

  - pre-load the list of Route headers to the request, 

  - insert an P-Asserted-Identity header with a value representing the
    initiator of the request; and

  - forward the request based on the topmost Route header.  When the
    P-CSCF receives any response to the above request, the P-CSCF
    shall:

  - remove any list of Record-Route headers, even though invalid, from
    the received response and forward it to the UE.  When the P-CSCF
    receives any request or response from the UE, the P-CSCF shall:

  - remove the <charging-vector XML element (see subclause 7.6), if
    present, from the message body of the received request or
    response.


5.2.6.4 Requests terminated by the UE

When the P-CSCF receives a response to an initial request for a dialog
or a response to a request for a standalone transaction, the P-CSCF
shall identify responder by a public user identity that relates to the
Request-URI used in the request.

NOTE: The contents of the To header do not form any part of this
decision process.  When the P-CSCF receives, destined for the UE, an
initial request for a dialog, or a refresh request for a dialog, prior
to forwarding the request, the P-CSCF shall:

  - remove its own SIP URL from the topmost Route header;

====HERE IT IS!!!====

  - remove the list of Record-Route headers, and shall convert it into
    a list of Route headers. The Contact header shall not be appended
    to the bottom of the list of Route headers. The P-CSCF shall save
    this list of Route headers and append this list to all UE
    originated requests for this dialog;

  - save the Contact header received in the response in order to
    release the dialog if needed;

  - add itself on the top of the removed list of Record-Route headers
    and save the list. The list will be appended to UE originated
    response to the SUBSCRIBE request;

  - remove and store the list of received Via headers from the
    received request and shall place its own address in the Via header
    with locally unique token to identify the saved values as a branch
    parameter. The P-CSCF shall append the list of Via headers to the
    UE originated response for this request;

  - store the values received in the P-Charging-Function-Addresses
    header; and

  - remove and store the icid parameter received in the
P-Charging-Vector header.

When the P-CSCF receives a 1xx or 2xx response to the above request,
the P-CSCF shall:

  - insert an P-Asserted-Identity header with a value representing the
    responder to the request;

  - append the saved list of Record-Route headers to the response;

  - append the saved list of Via headers to the response; and

  - store the dialog ID and associate it with the private user
    identity and public user identity involved in the session.  When
    the P-CSCF receives any other response to the above request, the
    P-CSCF shall:

  - append the saved list of Via headers to the response.

When the P-CSCF receives, destined for the UE, a request for a
stand-alone transaction, prior to forwarding the request, the P-CSCF
shall:

  - insert an P-Asserted-Identity header with a value representing the
    responder to the request;

  - remove and store the list of received Via headers from the
    received request and shall place its own address in the Via header
    with locally unique token to identify the saved values as a branch
    parameter. The P-CSCF shall append this list of Via headers to the
    UE originated response for this transaction;

  - store the values received in the P-Charging-Function-Addresses
    header; and

  - remove and store the icid parameter received in the
    P-Charging-Vector header.


When the P-CSCF receives any response to the above request, the P-CSCF
shall:

  - append the saved list of Via headers to the response; and

  - verify if the request relates to a dialog in which the originator
    of the request is involved. If the request does not relate to a
    dialog in which the originator is involved, then a 403 response
    shall be sent back to the originator.  When the P-CSCF receives,
    destined for the UE, a subsequent request for a dialog that is not
    a refresh request, prior to forwarding the request, the P-CSCF
    shall:

  - remove and store the list of received Via headers from the
    received request and shall place its own address in the Via header
    with locally unique token to identify the saved values as a branch
    parameter. The P-CSCF shall append this list of Via headers to the
    UE originated response for this transaction; and

  - remove and store the icid parameter from P-Charging-Identity
    header (see subclause 7.6).

When the P-CSCF receives any response to the above request, the P-CSCF
shall:

  - append the saved list of Via headers to the response.

When the P-CSCF sends any request or response to the UE, the P-CSCF
shall:

  - remove the P-Charging-Vector header from the request or response.


------------------------------------------------------------------------
-
Issue:

3) The P-CSCF may edit SDP sent from or to the UA in order to force
   the selection of codecs considered favorable to the operator. Yes,
   they think they're billing for bits on a per-minute basis.  This
   has the side effect of breaking ens-to-end protection of theSDP
   using S/MIME. We're negotiating this one, as Rosenberg has proposed
   a new mechanism by which a proxy may request SDP grooming from a
   UA. However, this is likely to require additional round trips over
   the air interface, and is not viewed favorably by the operators.

Reference:

6.2 Procedures at the P-CSCF

When the P-CSCF receives an INVITE request or reINVITE request, the
P-CSCF shall examine the media parameters in the received SDP, and
remove those which are not allowed on the network by local policy. The
P-CSCF will also remove those codecs from the approved media streams
which are not allowed by local policy. If the P-CSCF modifies the SDP,
it shall also revise the SDP to reflect the modified bandwidth
requirements. For the rejected media streams, the P-CSCF should ignore
the b= lines.



------------------------------------------------------------------------
Issue

4) The P-CSCF MAY (this is being fought) obfuscate the To: and From:
   fields in messages. This appear to be based on a particular
   interpretation of privacy regulation in certain European domains.
   It has the side effect of breaking end-to-end protection with
   S/MIME and breaking external services using the To: and From:
   fields, such as the most common forms of caller-ID used with SIP
   today.

ERROR SHOULD BE: "The S-CSCF may..."

5.4.3.2 Requests initiated by the served user

When the S-CSCF receives from the served user an initial request for a
dialog or a request for a standalone transaction, prior to forwarding
the request, the S-CSCF shall: - determine whether the request
contains a barred public user identity in the From or Remote-Party-ID
header fields of the request or not. In case any of the said header
fields contains a barred public user identity for the user, then the
S-CSCF shall reject the request by generating a 403 (Forbidden)
response. Otherwise, continue with the rest of the steps;

  - remove its own SIP URL from the topmost Route header;a

  - if the outgoing Request-URI is a TEL URL, the S-CSCF shall
    translate the E.164 address (see RFC 2806 [22]) to a globally
    routeable SIP URL using an ENUM/DNS translation mechanism with the
    format specified in RFC 2916 [24]. Databases aspects of ENUM are
    outside the scope of the present document. If this translation
    fails, the request may be forwarded to a BGCF or any other
    appropriate entity (e.g a MRFC to play an announcement) in the
    originator's home network or an appropriate SIP response shall be
    sent to the originator;

  - check if P-Original-Dialog-ID header is present in the incoming
    request. If present, it indicates an association with an existing
    dialog, the request has been sent from an Application Server in
    response to a previously sent request. The od-to-tag, od-from-tag
    and od-call-idparameter values from the P-Original-Dialog-ID
    header may be used as additional parameters when searching for
    existing dialogs. Local data shall be updated to indicate that
    this Application Server has been contacted for the initial
    request. The S-CSCF shall determine the next hop using initial
    filter criteria and local data on status of which Application
    Servers have been contacted. If the next hop is another
    Application Server, the S-CSCF shall retain the
    P-Original-Dialog-ID header in the request.  If the next hop is
    not an Application Server, the S-CSCF shall remove the
    P-Original-Dialog-ID header from the request;

  - check whether the initial request matches the initial filter
    criteria, the S-CSCF shall forward this request to that
    application server, then check for matching of the next following
    filter criteria of lower priority, and apply the filter criteria
    on the SIP method received from the previously contacted
    application server as described in 3GPP TS 23.218 [5] subclause
    6.4. Depending on the result of the previous process, the S-CSCF
    may contact one or more application server(s) before processing
    the outgoing Request-URI. In case of contacting one or more
    application server(s) the S-CSCF shall:

  - insert the AS URL to be contacted into the Route header as the
    topmost entry followed by its own URL; and

  - populate the P-Original-Dialog-ID header in the message with the
    original To tag, From tag and Call-ID headers received in the
    request. See subclause 7.2.7 for further information on the
    original dialog identifier;

  - store the value of the icid parameter received in the
    P-Charging-Vector header and retain the icid parameter in the
    P-Charging-Vector header. Optionally, the S-CSCF may generate a
    new, globally unique icid and insert the new value in the icid
    parameter of the P-Charging-Vector header when forwarding the
    message. If the S-CSCF creates a new icid, then it is responsible
    for maintaining the two icid values in the subsequent messaging;

  - insert an ioi-originating parameter into the P-Charging-Vector
    header if the next hop is an AS, I-CSCF or outside of the current
    network. The ioi-originating parameter shall be set to a value
    that identifies the sending network. The ioi-terminating parameter
    shall not be included;

  - insert a P-Charging-Function-Addresses header (see subclause
    7.2.5) populated with values received from the HSS if the message
    is forwarded within the S-CSCF home network, including towards AS;

  - in the case where the S-CSCF has knowledge of an associated
    tel-URI for a SIP URL contained in the received
    P-Asserted-Identity header, add a second P-Asserted-Identity
    header containing this tel-URI;

====HERE IT IS!!!====

  - in the case where the network operator has policy to provide
    privacy on From headers, and such privacy is required for this
    dialog, change the From header to "Anonymous". Network policy may
    also require the removal of the display field;

  - determine the destination address (e.g. DNS access) using the URL
    placed in the topmost Route header if present, otherwise based on
    the Request-URI;

  - if network hiding is needed due to local policy, put the address
    of the I-CSCF(THIG) to the topmost route header;

  - in case of an initial request for a dialog the S-CSCF shall create
    a Record-Route header containing its own SIP URL and save the
    necessary Record-Route header fields and the Contact header from
    the request in order to release the dialog when needed;

  - remove the P-Access-Network-Info header and act upon the contents
    accordingly; and

  - route the request based on SIP routeing procedures.




------------------------------------------------------------------------
---
Issue:

5) The P-CSCF filters messages from the UA to assure that only an
   identity known to the P-CSCF is presented by the UA. This may
   interact with the preceding characteristic. This appears to be
   required to accomodate the authorization model of 3GPP, which
   authenticates only REGISTER transactions and uses them to establish
   a security association between UA and P-CSCF. The side effect is
   that a 3GPP user may use only the operator-provided identity and
   may not be able to effectively use third-party services that
   provide other identities unless those services provide identity
   transformation with a back-to-back user agent.

Reference:

5.2.6.3 Requests initiated by the UE

When the P-CSCF receives an initial request for a dialog or a request
for a standalone transaction, and the request contains as
P-Asserted-Identity header that matches one of the registered public
user identities, the P-CSCF shall identify the initiator of the
request by that public user identity.  When the P-CSCF receives an
initial request for a dialog or a request for a standalone
transaction, and the request contains as P-Asserted-Identity header
that does not match one of the registered public user identities, or
does not contain a P-Asserted-Identity header, the P-CSCF shall
identify the initiator of the request by a default public user
identity.

NOTE: The contents of the From header do not form any part of this
decision process.  When the P-CSCF receives from the UE an initial
request for a dialog, and a P-Service-Route header list exists for the
initiator of the request, the P-CSCF shall:


5) The S-CSCF (or an application server, which may be colocated with
   the S-CSCF) may send a BYE both to and on behalf of of subscriber
   if the account runs out of money or is otherwise deactivated.  Of
   course, it doesn't have the credentials to authenticate the BYE, so
   many UAs will consider this as a forged message. The side effect is
   that 3GPP UAs become vulnerable to DoS attacks using forged BYEs.


5.4.5.1.2 Release of an existing session 

Upon receipt of a network internal indication to release an existing
multimedia session, the S-CSCF shall:

1) generate a first BYE request for the called user based on the
information saved for the related dialog, including:

  - a Request-URI, set to the stored Contact header provided by the
    called user;

  - a To header, set to the To header value as received in the 200 OK
    response for the initial INVITE request;

  - a From header, set to the From header value as received in the
    initial INVITE request;

  - a Call-ID header, set to the Call-Id header value as received in
    the initial INVITE request;

  - a CSeq header, set to the CSeq value that was stored for the
    direction from the calling to the called user, incremented by one;

  - a Route header, set to the routeing information towards the called
    user as stored for the dialog;

  - further headers, based on local policy or the requested session
    release reason.

2) generate a second BYE request for the calling user based on the
information saved for the related dialog, including:

  - a Request-URI, set to the stored Contact header provided by the
    calling user;

  - a To header, set to the From header value as received in the
    initial INVITE request;

  - a From header, set to the To header value as received in the 200
    OK response for the initial INVITE request;

  - a Call-ID header, set to the Call-Id header value as received in
    the initial INVITE request;

  - a CSeq header, set to the CSeq value that was stored for the
    direction from the called to the calling user, incremented by one
    $(H i(Bf no CSeq value was stored for that session it shall
    generate and apply a random number within the valid range for
    CSeqs;

  - a Route header, set to the routeing information towards the
    calling user as stored for the dialog;

  - further headers, based on local policy or the requested session
    release reason.

3) if the S-CSCF serves the calling user, treat the first BYE request
as if received directly from the calling user, i.e. send it to
internal service control and based on the outcome further on towards
the called user;

4) if the S-CSCF serves the calling user, send the second BYE request
directly to the calling user.

5) if the S-CSCF serves the called user, send the first BYE request
directly to the called user;

6) if the S-CSCF serves the called user, treat the second BYE request
as if received directly from the called user, i.e. shall send it to
internal service control and based on the outcome further on towards
to the called user.  Upon receipt of the 2xx responses for both BYE
requests, the S-CSCF shall release all information related to the
dialog and the related multimedia session.


---------------------------------------------------
Issue:

6) The I-CSCF (or THIG) may encrypt Via and Route information when
   acting in topology-hiding mode. This is similar to what many
   firewall systems using SIP do that are deployed by wireline
   operators. However, it does tend to interact with SIP proxy service
   instantiation using loose-routing techniques, and doing it right is
   very tricky.

Reference:

5.3.3 THIG functionality in the I-CSCF(THIG)

5.3.3.1 General

The following procedures shall only be applied if topology hiding is
required by the network. The network requiring topology hiding is
called the hiding network.  NOTE: Requests and responses are handled
independently therefore no state information is needed for that
purpose within an I-CSCF(THIG).

All headers which reveal topology information, such as Via, Route,
Record-Route, P-Service-Route, shall be subject to topology hiding.

Upon receiving an incoming REGISTER request for which topology hiding
has to be applied and which includes a Path header, the I-CSCF(THIG)
shall add the routeable SIP URL of an I-CSCF(THIG) to the top of the
Path header. The inserted SIP URL may include an indicator that
identifies the direction of subsequent requests received by the
I-CSCF. This indicator may e.g., be a unique header parameter, a
username or a dedicated port. Any subsequent request that includes
this indicator (in the Route header) or arrives at the dedicated port
indicates that the request was sent by the S-CSCF toward the P-CSCF.

Upon receiving an incoming initial request for which topology hiding
has to be applied and which includes a Record-Route header, the
I-CSCF(THIG) shall add its own routeable SIP URL to the top of the
Record-Route header.

Upon receiving an outgoing initial request for which topology hiding
has to be applied and which includes P-Charging-Function-Addresses
header, the I-CSCF(THIG) shall remove the
P-Charging-Function-Addresses header prior to forwarding the message.

5.3.3.2 Encryption for topology hiding

Upon receiving an outgoing request/response from the hiding network
the I-CSCF(THIG) shall perform the encryption for topology hiding
purposes, i.e. the I-CSCF(THIG) shall:

1) use the whole header values which were added by one or more
specific entity of the hiding network as input to encryption, besides
the UE entry;

2) not change the order of the headers subject to encryption when
performing encryption;

3) use for one encrypted string all received consecutive header
entries subject to encryption, regardless if they appear in separate
consecutive headers or if they are consecutive entries in a comma
separated list in one header;

4) construct an NAI in the form of 'username@realm',where the username
part is the encrypted string, and the realm is the name of the
encrypting network.

5) append a "tokenized-by=" tag and set it to the value of the
encrypting network's name, after the constructed NAI;

6) form one valid entry for the specific header out of the resulting
NAI, e.g.  prepend "SIP/2.0/UDP" for Via headers or "sip:" for Route
and Record-Route headers.

NOTE 1: Even if consecutive entries of the same network in a specific
header are encrypted, they will result in only one encrypted header
entry. For example:

Via: SIP/2.0/UDP icscf1_s.home1.net;lr, 
SIP/2.0/UDP Token( SIP/2.0/UDP scscf1.home1.net;lr, 
    SIP/2.0/UDP pcscf1.home1.net;lr)@home1.net;
     tokenized-by=home1.net, 
  SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]

NOTE 2: If multiple entries of the same network are within the same type
of headers, 
but they are not consecutive, then these entries will be tokenized to
different strings. 
For example:

Route: sip:icscf1_s.home1.net;lr, 
 
sip:Token(sip:scscf1.home1.net;lr)@home1.net;tokenized-by=home1.net,
     sip:as1.foreign.net;lr, 
     sip:Token(sip:scscf1.home1.net;lr, 
     sip:pcscf1.home1.net;lr)@home1.net;tokenized-by=home1.net, 
    sip:[5555::aaa:bbb:ccc:ddd]

5.3.3.3 Decryption for Topology Hiding

Upon receiving and incoming requests/response to the hiding network
the I-CSCF(THIG) shall perform the decryption for topology hiding
purposes, i.e. the I-CSCF shall:

1) identify NAIs encrypted by the network this I-CSCF belongs to
within all headers of the incoming message;

2) use the user part of those NAIs that carry the identification of
the hiding network within the value of the tokenized-by tag as input
to decryption;

3) use as encrypted string the user part of the NAI which follows the
sent-protocol (for Via Headers, e.g. "SIP/2.0/UDP") or the URI scheme
(for Route and Record-Route Headers, e.g. "sip:");

4) replace all content of the received header which carries encrypted
information with the entries resulting from decryption.

EXAMPLE: An encrypted entry to a Via header that looks like:
Via:  SIP/2.0/UDP Token(SIP/2.0/UDP scscf1.home1.net;lr, 
SIP/2.0/UDP pcscf1.home1.net;lr)@home1.net;tokenized-by=home1.net

will be replaced with the following entries:
Via: SIP/2.0/UDP scscf1.home1.net;lr, SIP/2.0/UDP pcscf1.home1.net;lr

NOTE: Motivations for these decryption procedures are e.g. to allow
the correct routeing of a response through the hiding network, to
enable loop avoidance within the hiding network, or to allow the
entities of the hiding network to change their entries within e.g. the
Record-Route header.



--------------------------------------------------------------
Issue:

7) All of the S-CSCF elements and various AS may manipulate message
   bodies. Manipulating message bodies in a proxy is forbidden in 
   RFC 3261 because it breaks end-to-end protection using S/MIME. 
   3GPP uses message bodies to attach material used intrasystem.
   This is very convenenient for them.


Reference:

6.3 Procedures at the S-CSCF

When the S-CSCF receives an INVITE request or reINVITE request, the
S-CSCF shall examine the media parameters in the received SDP, and
remove those media streams which are not allowed based on the
subscription. The S-CSCF will also remove those codecs from the
approved media streams which are not allowed by the subscription.  If
the S-CSCF modifies the SDP, it shall also revise the SDP to reflect
the modified bandwidth requirements. For the rejected media streams,
the S-CSCF should ignore the b= lines.


= Otherwise this was basically XML bodies which have now been
replaced by P-headers.

Remaining XML body issue is the Service-Info however in 24.229 this is
currently only written by the S-CSCF during 3rd party registration
with the AS. However the stage 2 in 23.218 does not restrict the
useage of this XML parameter to registration and my contribution at
the last CN1 meeting to restrict this to registration was not
accepted.  However it will require a CR to enhance the stage 3 for
other requests and this can also be objected by us. Anyway here is TS
24.229 text on the 3RD party register to AS:

5.4.1.7 Notification of Application Servers about registration status
If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4
or 5.4.1.5 
(as appropriate) was successful, the S-CSCF shall send a third-party
REGISTER request 
to each Application Server with the following information:

a) the Request-URI shall contain the AS's SIP URL;

b) the From header shall contain the S-CSCF's SIP URL;

c) the To header shall contain the public user identity as contained
in the REGISTER request received form the UE;

d) the Contact header shall contain the S-CSCF's SIP URL;

e) for initial registration and user-initiated reregistration
(subclause 5.4.1.2), the Expires header shall contain the same value
that the S-CSCF returned in the 200 (OK) response for the REGISTER
request received form the UE;

f) for user-initiated deregistration (subclause 5.4.1.4) and
network-initiated deregistration (subclause 5.4.1.5), the Expires
header shall contain the value zero;

g) for initial registration and user-initiated reregistration
(subclause 5.4.1.2),

====HERE IT IS!!!====

a message body shall be included in the REGISTER request if there is
Filter Criteria indicating the need to include HSS provided data for
the REGISTER event (e.g. HSS may provide AS specific data to be
included in the third-party REGISTER, such as IMSI to be delivered to
IM SSF). If there is a service information XML element provided in the
HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then it shall
be included in the message body of the REGISTER request within the
<service-info XML element as described in subclause 7.6. For the
messages including the 3GPP IMS XML body, set the value of the
Content-Type header to include the MIME type specified in subclause
7.6;

h) for initial registration, the P-Charging-Vector header shall
contain the same icid parameter that the S-CSCF received in the
original REGISTER request from the UE;

i) for initial registration, a P-Charging-Function-Addresses header
(see subclause 7.2.5) shall be populated with values received from the
HSS if the message is forwarded within the S-CSCF home network.