Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W… 
5.2 Procedures at the P-CSCF  5.2.1 General  5.2.2 Registration  5.2.2.1 General  5.2.2.2 IMS AKA as a security mechanism  5.2.2.3 SIP digest without TLS as a security mechanism  5.2.2.4 SIP digest with TLS as a security mechanism  5.2.2.5 NASS-IMS bundled authentication as a security mechanism  5.2.2.6 GPRS-IMS-Bundled authentication as a security mechanism  5.2.2.7 P-CSCF reconfigured to not accept registrations 
...

 

5.2  Procedures at the P-CSCF  p. 164

5.2.1  General  p. 164

Where the P-CSCF provides emergency call support, the procedures of subclause 5.2.10 shall be applied first.
Subclause 5.2.2 through subclause 5.2.9 define P-CSCF procedures for SIP that do not relate to emergency. All SIP requests are first screened according to the procedures of subclause 5.2.10 to see if they do relate to an emergency.
For all SIP transactions identified:
  • as relating to an emergency; or
  • if priority is supported, as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;
the P-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If the P-CSCF recognises the need for priority processing to a request or if the P-CSCF recognises the need to provide different priority processing than the one indicated by the originating UE, based on the information stored during registration, the P-CSCF may insert or modify Resource-Priority header in accordance with RFC 4412.
The P-CSCF shall support the Path and Service-Route header fields.
When the P-CSCF sends any request or response to the UE, before sending the message the P-CSCF shall:
  • remove the P-Charging-Function-Addresses and P-Charging-Vector header fields, if present.
When the P-CSCF receives any request or response from the UE, the P-CSCF:
  1. shall remove the P-Charging-Function-Addresses and P-Charging-Vector header fields, if present. Also, the P-CSCF shall ignore any data received in the P-Charging-Function-Addresses and P-Charging-Vector header fields; and
  2. may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message;
  3. shall remove the P-Access-Network-Info header field, if the request or the response include a P-Access-Network-Info header field with a "network-provided" parameter;
  4. may insert a P-Access-Network-Info header field where:
    1. if no mechanism exists to support the access technology for this UE, the "network-provided" parameter is included, and the access-type field is set to a preconfigured value;
    2. if NASS is used to support the access technology for this UE, the "network-provided" parameter is included, and the access-type field is set:
      • when xDSL is the IP-CAN, to one of "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", or "xDSL", and the "dsl-location" parameter is set with the value received in the Location-Information header field in the User-Data Answer command as specified in ETSI ES 283 035 [98];
      • when Ethernet is the IP-CAN, to one of "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u","IEEE-802.3ab"or "IEEE-802.3ae", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y" or "IEEE-802.3z" and if NASS subsystem is used, and the "eth-location" parameter is set with the value received in the Location-Information header field in the User-Data Answer command as specified in ETSI ES 283 035 [98];
      • when Fiber is the IP-CAN, to one of "G-PON", "XGPON1" or "IEEE-802.3ah" and if NASS subsystem is used, and the "fiber-location" parameter is set with the value received in the Location-Information header field in the User-Data Answer command as specified in ETSI ES 283 035 [98];
    3. if the PCRF is used to support the access technology for this UE and 3GPP-User-Location-Info as specified in TS 29.214 is not available:
      • if the IP-CAN-Type value provided by the PCRF is not "DVB-RCS2", then:
        1. the access-type field or the access-class field is set to a value consistent with that received from the PCRF in the IP-CAN-Type, RAT-Type and AN-Trusted parameters using the procedures specified in TS 29.214.
          If the IP-CAN-Type parameter is set "Non-3GPP-EPS (6)" as specified in TS 29.212, the RAT-Type parameter is set to "VIRTUAL (1)" as specified in TS 29.212 and the AN-Trusted parameter is set to "UNTRUSTED (1)" as specified in TS 29.273, the P-CSCF shall include the access-class field set to "untrusted-non-3GPP-VIRTUAL-EPC".
        2. if a 3GPP-MS-TimeZone parameter is available from the PCRF, then the "local-time-zone" parameter and the "daylight-saving-time" parameter may also be added using this information;
        3. the "network-provided" parameter is added;
        4. if a TWAN-Identifier as specified in TS 29.214 is received from the PCRF, the received TWAN-Identifier contains the Circuit-ID and the associated "Relay Identity", the received TWAN-Identifier does not contain the "Civic Address Information" and the P-CSCF is able to deduce a Geographical Identifier from the Circuit-ID and the associated "Relay Identity", then, if required by local operator policy, the P-CSCF shall include an operator-specific-GI field. The P-CSCF can obtain a Geographical Identifier from the CLF by using the e2 interface (see ETSI ES 283 035 [98]);
        5. if WLAN Location Information as specified in TS 23.402 is received from the PCRF, the received WLAN Location Information contains the location identifier and the P-CSCF is able to deduce a Geographical Identifier from the WLAN Location Information, then, if required by local operator policy, the P-CSCF shall include an operator-specific-GI field; and
        6. if:
          1. the access-class field of the P-Access-Network-Info header field is set to "untrusted-non-3GPP-VIRTUAL-EPC"; or
          2. the access-class field of the P-Access-Network-Info header field is set to "3GPP-WLAN" and the AN-Trusted parameter specified in TS 29.273 is received from PCRF and is set to "UNTRUSTED (1)";
          then:
          1. if a UE-Local-IP-Address parameter specified in TS 29.212 is received from the PCRF and if required by local operator policy, P-CSCF shall also include in the P-Access-Network-Info header field a UE-local-IP-address parameter set to the UE local IP address in the UE-Local-IP-Address parameter received from PCRF;
          2. if a UDP-Source-Port parameter specified in TS 29.212 is received from the PCRF and if required by local operator policy, the P-CSCF shall also include in the P-Access-Network-Info header field a UDP-source-port parameter set to the UDP port in the UDP-Source-Port parameter received from PCRF;
          3. if a TCP-Source-Port parameter specified in TS 29.212 is received from the PCRF and if required by local operator policy, the P-CSCF shall also include in the P-Access-Network-Info header field a TCP-source-port parameter set to the TCP port in the TCP-Source-Port parameter received from PCRF; and
          4. if an AN-GW-Address parameter specified in TS 29.212 is received from the PCRF and if required by local operator policy, the P-CSCF shall also include in the P-Access-Network-Info header field an ePDG-IP-address parameter set to the ePDG IP address in the ePDG-IP-Address parameter received from PCRF; and
        7. if the P-CSCF supports reporting EPS fallback, then the "eps-fallback" parameter is included, if the information is available to the P-CSCF; and
      • if the IP-CAN-Type value provided by the PCRF is "DVB-RCS2", then the "network-provided" parameter is included, the access-type field is set to "DVB-RCS2", and the "dvb-rcs2-node-id" parameter is set with the value provided by the IP-CAN provider;
    4. if the PCRF is used to support the access technology for this UE and 3GPP-User-Location-Info as specified in TS 29.214 is available;
      1. the access-type field or the access-class field is set to a value consistent with that received from the PCRF in the IP-CAN-Type and RAT-Type parameters;
      2. the access-info field is set to a value consistent with the information received from the PCRF in the 3GPP-User-Location-Info parameter;
      3. if a 3GPP-MS-TimeZone parameter is available from the PCRF, then the "local-time-zone" parameter and the "daylight-saving-time" parameter may also be added using this information;
      4. the "network-provided" parameter is added;
      5. if required by local operator policy and the P-CSCF is able to deduce a Geographical Identifier from the Cell Global Identity (CGI) or form the Service Area Identifier (SAI) received from the PCRF, the P-CSCF shall include an operator-specific-GI field. The P-CSCF can obtain a Geographical Identifier from the CLF by using the e2 interface (see ETSI ES 283 035 [98]); and
      6. if the P-CSCF supports reporting EPS fallback then the "eps-fallback" parameter is included, if the information is available to the P-CSCF; and
    5. if DOCSIS is used, and proprietary means of obtaining a location are used, the access-type field is set to "DOCSIS" and the "network-provided" parameter is added; and
    6. if none of NASS, PCRF and DOCSIS are used to support the access technology for the UE and the IP-CAN is not provided by the packet switched domain of the PLMN of the P-CSCF:
      1. if the P-CSCF is unaware of the radio access technology used by the UE, the access-class field is set to "VIRTUAL-no-PS";
      2. if the P-CSCF is aware that the radio access technology used by the UE is specified by IEEE Std 802.11 [248], the access-class field is set to "WLAN-no-PS"; and
      3. the "network-provided" parameter is added;
  5. shall remove all Feature-Caps header fields, if present, from a UE that is not considered as privileged sender;
  6. may insert a P-Visited-Network-ID header field (except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE) according to RFC 7976 with the value:
    1. of a pre-provisioned string that identifies the network of the P-CSCF at the home network; or
    2. if the UE is roaming in deployments without IMS-level roaming interfaces according to TS 23.228, a string that identifies the visited network of the UE including an indication that the P-CSCF is located in the home network;
  7. may insert a P-Visited-Network-ID header field in 200 (OK) response to INVITE request and in 200 (OK) response to MESSAGE request according to draft-jesske-update-p-visited-network [52B]; and
  8. if a Geolocation header field is received from the UE, shall remove any present loc-src parameter from the Geolocation header field.
When the P-CSCF receives any request or response containing the P-Media-Authorization header field, the P-CSCF shall remove the header field.
With the exception of 305 (Use Proxy) responses, the P-CSCF shall not recurse on 3xx responses.
The P-CSCF may add, remove, or modify, the P-Early-Media header field within forwarded SIP requests and responses according to procedures in RFC 5009.
When SIP digest without TLS is used, the P-CSCF shall discard any SIP messages received outside of the registration and authentication procedures that do not map to an existing IP association as defined in subclause 5.2.3.
In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT controlled by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in Annex F. In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT not controlled by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in Annex K if both a "reg-id" and "+sip.instance" header field parameters are present in the received Contact header field as described in RFC 5626.
The P-CSCF shall support the provision of the user-related policies (e.g. consideration of the user as a privileged sender):
  • from the S-CSCF during registration; and
  • by local configuration.
For the same policy, the precedence between the locally configured policy and a policy received during registration shall be based on local operator policy.
For UE performing the functions of an external attached networks using static mode of operation, the P-CSCF will receive requests to establish a TLS session that are not accompanied by the associated procedures of subclause 5.2.2. The P-CSCF shall permit the establishment of such TLS sessions, but subsequent operations without the reception of a REGISTER request shall only be permitted if the P-CSCF is configured for such a UE performing the functions of an external attached network using static mode of operation. Where a REGISTER request is received from a UE, the P-CSCF shall process the REGISTER request as defined in subclause 5.2.2, and shall not provide special procedures for a UE performing the functions of an external attached network using static mode of operation for the duration of the registration.
When sending a failure response to any received request, depending on operator policy, the P-CSCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "p-cscf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. A P-CSCF when sending a failure response will add in the URN the "side" header field parameter set to:
  • "orig" for a UE-originating case; and
  • "term" for a UE-terminating case.
Up

5.2.2  Registration  p. 168

5.2.2.1  General |R8|  p. 168

The P-CSCF shall be prepared to receive the unprotected REGISTER requests on the SIP default port values as specified in RFC 3261. The P-CSCF shall also be prepared to receive the unprotected REGISTER requests on the port advertised to the UE during the P-CSCF discovery procedure.
The P-CSCF shall distinguish between security mechanisms through the use of the Security-Client header field and Authorization header field as follows:
  1. if a REGISTER request from the UE contains a Security-Client header field and the Require and Proxy-Require header fields contain "sec-agree", then for an initial registration, the P-CSCF shall select the sec-mechanism and mode (as described in Annex H of TS 33.203) from the corresponding parameters offered in the Security-Client header field according to its priorities, as follows:
    • if the P-CSCF selects the sec-mechanism "ipsec- 3gpp" then follow the procedures as described in subclause 5.2.2.2, in addition to the procedures described in this subclause;
    • if the P-CSCF selects the sec-mechanism "tls" then follow the procedures as described in subclause 5.2.2.4, in addition to the procedures described in this subclause.
  2. if:
    1. a REGISTER request from the UE does not contain a Security-Client header field;
    2. a REGISTER request from the UE contains a Security-Client header field containing only media plane security mechanisms and the Require and Proxy-Require header fields do not contain "sec-agree"; or
    3. the P-CSCF does not select any signalling plane security mechanism from the Security-Client header field;
    then the P-CSCF shall behave as follows, in addition to the procedures described in the remainder of this subclause:
    • if the REGISTER request does not contain an Authorization header field and was received over an access network defined in 3GPP specifications then follow the GPRS-IMS-Bundled authentication procedures as described in subclause 5.2.2.6; or
    • if the REGISTER request does not contain an Authorization header field and was received over a TISPAN NASS and the P-CSCF supports both SIP digest and NASS-IMS bundled authentication, then the P-CSCF shall perform the steps required for NASS-IMS bundled authentication, in subclause 5.2.2.5, as well as the steps required for SIP digest without TLS, in subclause 5.2.2.3, unless it is configured to behave differently or the P-CSCF only supports either SIP digest without TLS or NASS-IMS bundled authentication. If the NASS-IMS bundled authentication related query from the P-CSCF to the TISPAN NASS fails, then the P-CSCF shall only continue with the SIP digest related steps; or
    • if the REGISTER request does not contain an Authorization header field, and was received over an access other than defined in 3GPP specifications or TISPAN NASS, then follow the SIP digest without TLS procedures described in subclause 5.2.2.3; or
    • if the REGISTER request contains an Authorization header field with an "algorithm" header field parameter set to "AKAv2-SHA-256" and the REGISTER request was received by eP-CSCF over TLS, then follow the IMS-AKA procedures for eP-CSCF defined in TS 24.371; or
    • if the REGISTER request contains an Authorization header field without an "algorithm" header field parameter set to "AKAv2-SHA-256" and was not received over a TISPAN NASS then follow the SIP digest without TLS procedures as described in subclause 5.2.2.3; or
    • if the REGISTER request contains an Authorization header field and was received over a TISPAN NASS, and the P-CSCF supports both SIP digest and NASS-IMS bundled authentication, then the P-CSCF shall perform the steps required for NASS-IMS bundled authentication, in subclause 5.2.2.5, as well as the steps required for SIP digest without TLS, in subclause 5.2.2.3, unless it is configured to behave differently. If the NASS-IMS bundled authentication related query from the P-CSCF to the TISPAN NASS fails, then the P-CSCF shall only continue with the SIP digest related steps.
    For subsequent registrations, the P-CSCF shall continue to use the selected mechanism.
When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall:
1)
insert a Path header field in the request including an entry containing:
  • the SIP URI identifying the P-CSCF;
  • an indication that requests routed in this direction of the path (i.e. from the S-CSCF towards the P-CSCF) are expected to be treated as for the UE-terminating case;
  • an IMS flow token in the user portion of the P-CSCF's SIP URI inserted into the Path header field, and the "ob" SIP URI parameter according to RFC 5626. The same SIP URI (user portion, hostport parameter and SIP URI parameters) shall be used for the initial registration, and the reregistrations, binding fetchings, and de-registration that refreshes of the respective registration;
  • the P-CSCF shall use a different IMS flow token for each registration. If the multiple registration mechanism is used, the P-CSCF shall also use a different IMS flow token for each registration flow associated with the registration;
  • if
    1. the P-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549;
    2. the UE is roaming;
    3. the P-CSCF is not in the home network; and
    4. required by local policy;
    then the P-CSCF may append an "iotl" SIP URI parameter with a value set to "homeB-visitedB" to the SIP URI of the Path header field;
2)
insert a Require header field containing the option-tag "path";
3)
insert a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;
4)
insert a P-Visited-Network-ID header field, with the value:
  • of a pre-provisioned string that identifies the network of the P-CSCF at the home network; or
  • if the UE is roaming in deployments without IMS-level roaming interfaces according to TS 23.228, a string that identifies the visited network of the UE including an indication that the P-CSCF is located in the home network.
    EXAMPLE:
    A UE is roaming using a deployment without an IMS-level roaming interface and the P-CSCF receives via Rx interface a MCC with the value "111" and a MNC with the value "22" identifying the visited network. The domain name of the home network where the P-CSCF is located has the value "networkoperator". In this case, the P-CSCF can set up the P-Visited Network-ID header with a string which can look like: "s8hr.mnc22.mcc111.networkoperator".
    • 4A)
    store the announcement of the media plane security mechanisms the UE supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Client header field, if any. Also, if the Security-Client header field contains only media plane security mechanisms, remove the header field;
    4B)
    if the REGISTER request contains an Authorization header field, remove the "integrity-protected" header field parameter, if present;
    4C)
    if the host portion of the sent-by field in the topmost Via header field contains a FQDN, or if it contains an IP address that differs from the source address of the IP packet, the P-CSCF shall add a "received" Via header field parameter in accordance with the procedure defined in RFC 3261;
    5)
    if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network:
    1. if the request is not to be forwarded to an ATCF according to local policy select an exit point in visited network;
    2. if the request is to be forwarded to an ATCF according to local policy:
      1. insert a Route header field with the ATCF URI for originating requests; and
      2. forward the request; and
    3. if the request is not to be forwarded to an ATCF according to local policy, then forward the request to the selected exit point.
    If:
    • no response is received to the REGISTER request and its retransmissions by the P-CSCF; or
    • a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request is received;
    the P-CSCF shall repeat the actions of this bullet with a different exit point or a different ATCF.
    If the P-CSCF fails to forward the REGISTER request to any exit point or any ATCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 unless local policy allows omitting the exit point;
    6)
    if the P-CSCF is located in the visited network and local policy does not require the application of IBCF capabilities in the visited network towards the home network:
    1. if the request is not to be forwarded to an ATCF according to local policy select an entry point of the home network;
    2. if the request is to be forwarded to an ATCF according to local policy:
      1. insert a Route header field with the ATCF URI for originating requests; and
      2. forward the request; and
    3. if the request is not to be forwarded to an ATCF according to local policy, then forward the request to the selected entry point.
    If:
    • no response is received to the REGISTER request and its retransmissions by the P-CSCF; or
    • a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request is received;
    the P-CSCF shall repeat the actions of this bullet with a different entry point or a different ATCF.
    If the P-CSCF fails to forward the REGISTER request to any entry point or any ATCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261;
    7)
    if the P-CSCF is located in the home network:
    1. if the request is not to be forwarded to an ATCF according to local policy select the I-CSCF of the home network;
    2. if the request is to be forwarded to an ATCF according to local policy:
      1. insert a Route header field with the ATCF URI for originating requests; and
      2. forward the request; and
    3. if the request is not to be forwarded to an ATCF according to local policy, then forward the request to the selected I-CSCF.
    If:
    • no response is received to the REGISTER request and its retransmissions by the P-CSCF; or
    • a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request is received;
    the P-CSCF shall repeat the actions of this bullet with a different I-CSCF or a different ATCF.
    If the P-CSCF fails to forward the REGISTER request to any I-CSCF or any ATCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261; and
    8)
    void.
    When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of the registration expiration interval value. When the registration expiration interval value is different than zero, then the P-CSCF shall:
    1)
    save the list of service route values in the Service-Route header fields preserving the order, and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used) and the associated security association or TLS session over which the REGISTER request was received. The P-CSCF shall store this list during the entire registration period of the respective public user identity and bind it either to the associated contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used). The P-CSCF shall use this list to validate the routeing information in the requests originated by the UE using either the respective contact address or the registration flow and the associated contact address, and received over the respective security association or a TLS session. If the list of Service-Route header fields already exists either for this contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used), then the P-CSCF shall replace the already existing list of service route values with the list of Service-Route header fields received in the 200 (OK) response;
    2)
    associate the list of service route values with the registered public user identity and either the associated contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used) and the associated security association or TLS session;
    3)
    store the public user identities, found in the P-Associated-URI header field value, including any associated display names, and any parameters associated with either the user or the identities of the user, and associate them to the registered public user identity, i.e. the registered public user identity and its associated set of implicitly registered public user identities are bound to the contact address and security association or TLS session over which the REGISTER request was received;
    3A)
    if the user-related policies statically provisioned to the P-CSCF (see subclause 5.2.1) indicate that the URIs contained in the P-Associated-URI header field shall not be forwarded towards the UE, and the P-CSCF is located in the home operator network of the UE, then the P-CSCF shall remove all but the first URI contained in the P-Associated-URI header field of the 200 (OK) response;
    4)
    store the default public user identity, including its associated display name, if provided, for use with procedures for the P-Asserted-Identity header field for requests received from the UE over the respective security association or TLS session. The default public user identity is the first on the list of URIs present in the P-Associated-URI header field;
    5)
    store the values received in the P-Charging-Function-Addresses header field;
    6)
    if a "term-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "term-ioi" header field parameter;
    7)
    if the P-CSCF included an IMS flow token and the "ob" SIP URI parameter in the Path header field of the REGISTER request, check for presence of the option-tag "outbound" in the Require header field of the a 200 (OK) response:
    • if the option-tag "outbound" is present, it indicates that the UE has successfully registered its public user identity with a new bidirectional flow as defined in RFC 5626. In this case the P-CSCF shall route the subsequent requests and responses destined for the UE as specified in RFC 5626; or
    • if the option-tag "outbound" is not present, it indicates that the public user identity has not been registered as specified in RFC 5626. In this case the P-CSCF shall route the subsequent requests and responses destined for the UE as specified in RFC 3261;
    8)
    if the P-CSCF detects that the UE is behind a NAT, and the UE's Via header field contains a "keep" header field parameter, the P-CSCF shall add a value to the parameter, to indicate that it is willing to receive keep-alives associated with the registration from the UE, as defined in RFC 6223;
    9)
    void; and
    10)
    if the P-CSCF is located in the visited network, store the value of a "+g.3gpp.thig-path" Feature-Caps header field parameter, defined in subclause 7.9A.9, if included in the response. The P-CSCF shall remove the "+g.3gpp.thig-path" Feature-Caps header field parameter before forwarding the 200 (OK) response to the UE.
    If the P-CSCF detects that the UE is behind a NAT, and the request was received over a TCP connection, the P-CSCF shall not close the TCP connection during the duration of the registration.
    Up

    5.2.2.2  IMS AKA as a security mechanism |R8|  p. 174

    When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1)
    insert the "integrity-protected" header field parameter (described in subclause 7.2A.2) with a value "yes" into the Authorization header field in case the REGISTER request was either received protected with the security association created during an ongoing authentication procedure and includes an authentication challenge response (i.e. RES parameter), or it was received on the security association created during the last successful authentication procedure, otherwise insert the parameter with the value "no";
    1A)
    if the "reg-id" header field parameter was included in the Contact header field of the REGISTER request, insert in the Path header an IMS flow token and the "ob" URI parameter according to RFC 5626. The IMS flow token shall identify the flow from the P-CSCF toward the UE, as follows:
    1. for UDP, the IMS flow token identifies the unidirectional flow from the P-CSCF's protected client port and the P-CSCF's IP address to the UE's protected server port and the UE's IP address. This flow is used by the P-CSCF to send requests and responses to the UE. The P-CSCF shall receive the requests and responses from the UE on its protected server port; or
    2. for TCP, the IMS flow token identifies the existing TCP connection between the UE and the P-CSCF. This TCP connection is established by the P-CSCF, i.e. from the P-CSCF's protected client port and the P-CSCF's IP address to the UE's protected server port and the UE's IP address. This TCP connection is used to send SIP requests from the P-CSCF to the UE and receive SIP responses from the UE to the P-CSCF;
    2)
    in case the REGISTER request was received without protection, on the default port or port advertised to UE for P-CSCF discovery:
    1. check the existence of the Security-Client header field. If the Security-Client header field is present, then remove and store it. If the Security-Client header field is not present, then the P-CSCF shall return a suitable 4xx response;
    2. if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field to the source port of the received REGISTER request;
    3. insert the "received" header field parameter in the Via header field containing the source IP address that the request came from, as defined in RFC 3581; and
    3)
    in case the REGISTER request was received protected, then towards the port that was notified to the UE in the previous response:
    1. check the security association which protected the request. If the security association is a temporary one, then the request is expected to contain a Security-Verify header field in addition to a Security-Client header field. If there are no such header fields, then the P-CSCF shall return a suitable 4xx response. If there are such header fields, then the P-CSCF shall compare the content of the Security-Verify header field with the content of the Security-Server header field sent earlier and the content of the Security-Client header field with the content of the Security-Client header field received in the challenged REGISTER request. If those do not match, then there is a potential man-in-the-middle attack. The request should be rejected by sending a suitable 4xx response. If the contents match, the P-CSCF shall remove the Security-Verify and the Security-Client header field;
    2. if the security association the REGISTER request was received on, is an already established one, then:
      • the P-CSCF shall remove the Security-Verify header field if it is present;
      • a Security-Client header field containing new parameter values is expected. If the Security-Client header field or any required parameter is missing, then the P-CSCF shall return a suitable 4xx response; and
      • the P-CSCF shall remove and store the Security-Client header field before forwarding the request to the S-CSCF;
    3. check if the private user identity conveyed in the Authorization header field of the protected REGISTER request is the same as the private user identity which was previously challenged or authenticated. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response; and
    4. ignore the "rport" Via header field parameter, if included.
    When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall:
    1)
    delete any temporary set of security associations established towards the UE;
    2)
    remove the "ck" and "ik" WWW-Authenticate header field parameters contained in the 401 (Unauthorized) response and bind the values to the proper private user identity and to the temporary set of security associations which will be setup as a result of this challenge. The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the "ck" and "ik" header field parameters have been removed;
    3)
    insert a Security-Server header field in the response, containing the P-CSCF static signalling plane security list and the parameters needed for this security association setup, as specified in Annex H of TS 33.203. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329. The P-CSCF shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in TS 33.203 and shall announce support for them according to the procedures defined in RFC 3329;
    3A)
    insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;
    4)
    set up the temporary set of security associations for this registration with a temporary SIP level lifetime between the UE and the P-CSCF for the user identified with the private user identity. For further details see TS 33.203 and RFC 3329. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; and
    5)
    send the 401 (Unauthorized) response to the UE using the security association with which the associated REGISTER request was protected, or unprotected in case the REGISTER request was received unprotected. If the 401 (Unauthorized) response to the unprotected REGISTER request is sent using UDP, the P-CSCF shall send the response to the IP address listed in the "received" Via header field parameter and the port in the "rport" Via header field parameter. In case of TCP, the P-CSCF shall send the response over the same TCP connection over which the request was received from the UE.
    When the P-CSCF receives a 200 (OK) response to a REGISTER request as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1. if an existing set of security association is available, set the SIP level lifetime of the security association to the longest of either the previously existing security association lifetime, or the lifetime of the just completed registration plus 30 seconds;
    2. if a temporary set of security associations exists, change the temporary set of security associations to a newly established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 30 seconds; and
    3. protect the 200 (OK) response to the REGISTER request within the same security association to that in which the REGISTER request was protected.
    If the P-CSCF receives a SIP message (including REGISTER requests) from the UE over the newly established set of security associations that have not yet been taken into use, the P-CSCF shall:
    1. reduce the SIP level lifetime of the old set of security associations towards the same UE to 64*T1 (if currently longer than 64*T1); and
    2. use the newly established set of security associations for further messages sent towards the UE as appropriate (i.e. take the newly established set of security associations into use).
    When the SIP level lifetime of an old set of security associations is about to expire, i.e. their SIP level lifetime is shorter than 64*T1 and a newly established set of security associations has not been taken into use, the P-CSCF shall use the newly established set of security associations for further messages towards the UE as appropriate (see NOTE 2).
    When sending the 200 (OK) response for a REGISTER request that concludes a re-authentication, the P-CSCF shall:
    1. keep the set of security associations that was used for the REGISTER request that initiated the re-authentication;
    2. keep the newly established set of security associations created during this authentication; and
    3. go on using for further requests sent towards the UE the set of security associations and associated contact address that was used to protect the REGISTER request that initiated the re-authentication as appropriate (see NOTE 6).
    When sending the 200 (OK) respone for a REGISTER request that concludes an initial authentication of the user registering its public user identity with a given contact address the associated security association, i.e. the REGISTER request that initiated the authentication was received unprotected, the P-CSCF shall:
    1. keep the newly established set of security associations created during this authentication; and
    2. use the kept newly established set of security associations and associated contact address for further messages sent towards the UE as appropriate (see NOTE 6).
    The P-CSCF shall delete any security association from the IPsec database when their SIP level lifetime expires.
    The handling of the security associations at the P-CSCF is summarized in Table 5.2.2-1.
    Temporary set of security associations Newly established set of security associations Old set of security associations
    SIP message received over newly established set of security associations that have not yet been taken into useNo actionTake into useReduce SIP level lifetime to 64*T1, if lifetime is larger than 64*T1
    SIP message received over old set of security associationsNo actionNo actionNo action
    Old set of security associations currently in use will expire in 64*T1No actionTake into useNo action
    Sending an authorization challenge within a 401 (Unauthorized) response for a REGISTER requestCreate
    Remove any previously existing temporary set of security associations     		No actionNo action
    Sending 200 (OK) response for REGISTER request that concludes re-authenticationChange to a newly established set of security associationsConvert to and treat as old set of security associations (see next column)Continue using the old set of security associations over which the REGISTER request, that initiated the re-authentication was received.
    Delete all other old sets of security associations immediately
    Sending 200 (OK) response for REGISTER request that concludes initial authenticationChange to a newly established set of security associations and take into use immediatelyConvert to old set of security associations, i.e. deleteDelete
    Up

    5.2.2.3  SIP digest without TLS as a security mechanism |R8|  p. 177

    When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1. if the REGISTER request includes an Authorization header field update the "integrity-protected" header field parameter as follows:
      1. if the REGISTER request does not map to an existing IP association, and does not contain a challenge response, not include the "integrity-protected" header field parameter; or
      2. if the REGISTER request does not map to an existing IP association, and does contain a challenge response, include an "integrity-protected" header field parameter with the value set to "ip-assoc-pending"; or
      3. if the REGISTER request does map to an existing IP association, include an "integrity-protected" header field parameter with the value set to "ip-assoc-yes";
    2. if the P-CSCF adds a "received" header field parameter and UDP is being used, also add an "rport" Via header field parameter with the IP source port of the received REGISTER request; and
    3. if the REGISTER request does not contain an Authorization header field and the requests was received over a non 3GPP access network, insert a P-Access-Network-Info header field as described in subclause 5.2.1 step 4).
    If the P-CSCF receives a 500 (Server Internal Error) or 504 (Server Time-Out) response to a REGISTER request, and if the REGISTER request is mapped to an existing IP association, then the P-CSCF shall delete the IP association.
    When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall:
    1. insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7; and
    2. send the 401 (Unauthorized) response to the UE unprotected as defined in Section 4 of RFC 3581.
    When the P-CSCF receives a 200 (OK) response to a REGISTER request as defined in subclause 5.2.2.1, and the registration expiration interval value is different than zero, the P-CSCF shall additionally:
    1. create an IP association by storing and associating the UE's packet source IP address and port along with the "sent-by" parameter of the Via header field, cf. RFC 3261, of the REGISTER request with the private user identity and all the successfully registered public user identities related to that private user identity;
    2. overwrite any existing IP association which has the same pair of IP address and port, but a different private user identity; and
    3. send the 200 (OK) response to the UE unprotected as defined in Section 4 of RFC 3581.
    Up

    5.2.2.4  SIP digest with TLS as a security mechanism |R8|  p. 178

    TLS is optional to implement and is used only in combination with SIP digest authentication. If the P-CSCF supports TLS, then the P-CSCF shall support TLS as described in TS 33.203. If the P-CSCF supports TLS, the P-CSCF shall support TLS ciphersuites as described in TS 33.203.
    When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1)
    in case the REGISTER request was received without protection on the default port or port advertised to UE for P-CSCF discovery and with the Security-Client header field indicating "tls", then:
    1. remove and store the Security-Client header field;
    2. do not include the "integrity-protected" header field parameter in the Authorization header;
    3. if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header to the source port of the received REGISTER request; and
    4. insert the "received" header field parameter in the Via header containing the source IP address that the request came from, as defined in RFC 3581;
    2)
    if the REGISTER request was received protected with a TLS session, on the protected server port, created during an ongoing authentication procedure, where the Session ID for the TLS session is not yet bound to a private user identity, and contains an authentication challenge response (i.e. response parameter), then:
    1. check if the private user identity conveyed in the Authorization header of the protected REGISTER request is the same as the private user identity which was previously challenged. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response;
    2. check the existence of the Security-Verify header field and the Security-Client header field. If there are no such headers, then the P-CSCF shall return a suitable 4xx response. If there are such headers, then the P-CSCF shall compare the content of the Security-Verify header field with the content of the Security-Server header field sent earlier and the content of the Security-Client header field with the content of the Security-Client header field received in the challenged REGISTER request. If those do not match, then there is a potential man-in-the-middle attack. The P-CSCF should reject the request by sending a suitable 4xx response. If the contents match, the P-CSCF shall remove the Security-Verify and the Security-Client header fields;
    3. include an "integrity-protected" header field parameter with the value set to "tls-pending"; and
    4. if the hostport parameter in the Contact header field is in the form of a FQDN, the P-CSCF shall ensure that the given FQDN will resolve (e.g. by reverse DNS lookup) to the IP address bound to the TLS session; or
    2A)
    if the REGISTER request was received, protected with a TLS session on the protected server port, created during an ongoing authentication procedure, where the Session ID for the TLS session is not yet bound to a private user identity, and does not contain an authentication challenge response (i.e. response parameter), reject the REGISTER request by returning a 403 (Forbidden) response;
    3)
    if the REGISTER request was received on an existing TLS session created during a previous authentication procedure, then:
    1. if the REGISTER request includes an Authorization header field, check if the private user identity conveyed in the Authorization header of the protected REGISTER request is the same as the private user identity which was previously authenticated, i.e. the private user identity previously associated with the Session ID for this TLS session. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response;
    2. check the existence of the Security-Verify header field and Security-Client header field. If there are no such header fields, then the P-CSCF shall return a suitable 4xx response. If there are such headers, then the P-CSCF shall compare the content of the Security-Verify header field with the content of the Security-Server header field sent earlier and the content of the Security-Client header field with the content of the Security-Client header field received in the challenged REGISTER request. If those do not match, then there is a potential man-in-the-middle attack. The P-CSCF should reject the request by sending a suitable 4xx response;
    3. the P-CSCF shall remove and store the Security-Client header field and remove the Security-Verify header field before forwarding the request to the S-CSCF; and
    4. include an "integrity-protected" header field parameter with the value set to "tls-yes".
    If the P-CSCF require security agreement, and the Security-Client header field is not present, then the P-CSCF shall return a suitable 4xx response.
    When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall:
    1)
    insert a Security-Server header field in the response, containing the P-CSCF selected signalling plane mechanism name, as specified in Annex H of TS 33.203. The P-CSCF shall support and indicate the "tls" security mechanism, as specified in RFC 3329. The P-CSCF shall support the TLS ciphersuites as described in TS 33.203 and shall announce support for them according to the procedures defined in RFC 3329; and
    1A)
    insert a Security-Server header field in the response, containing the P-CSCF static media plane security list, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;
    2)
    send the 401 (Unauthorized) response to the UE using the TLS session with which the associated REGISTER request was protected, or unprotected in case the REGISTER request was received unprotected. If the 401 (Unauthorized) response to the unprotected REGISTER request is sent using UDP, the P-CSCF shall send the response to the IP address listed in the "received" header field parameter and the port in the "rport" header field parameter. In case of TCP, the P-CSCF shall send the response over the same TCP connection over which the request was received from the UE.
    When the P-CSCF receives a 200 (OK) response to a REGISTER request as defined in subclause 5.2.2.1, and the registration expiration interval value is different than zero, the P-CSCF shall additionally:
    • create an association by storing and associating the UEs IP address and port of the TLS connection with the TLS Session ID, the private user identity and all the successfully registered public user identities related to that private user identity; and
    • protect the 200 (OK) response to the REGISTER request within the same TLS session to that in which the request was protected.
    Up

    5.2.2.5  NASS-IMS bundled authentication as a security mechanism |R8|  p. 180

    When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1. perform the NASS-IMS bundled authentication related query from the P-CSCF to the TISPAN NASS;
    2. if the query in step 1) is successful, insert a P-Access-Network-Info header field as described in subclause 5.2.1 step 4); and
    3. if the P-CSCF adds a "received" header field parameter and UDP is being used, the P-CSCF shall also add an "rport" Via header field parameter with the IP source port of the received REGISTER request.
    When the P-CSCF receives a 200 (OK) response to a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1. store an association between the IP source address and port of the initial REGISTER request and the public user identities found in the P-Associated-URI header field value and associate them to the public user identity under registration;
    2. store an association between the IP source address and port of the initial REGISTER request the default public user identity for use with procedures for the P-Asserted-Identity header field. The default public user identity is the first on the list of URIs present in the P-Associated-URI header field; and
    3. insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7.
    Up

    5.2.2.6  GPRS-IMS-Bundled authentication as a security mechanism |R8|  p. 180

    When the P-CSCF receives a SIP request from a GPRS-IMS-Bundled UE, the P-CSCF checks the IP address in the "sent-by" parameter of the Via header field provided by the UE as specified in RFC 3261. If the "sent-by" parameter contains a domain name, or if it contains an IP address that differs from the packet source IP address, the P-CSCF adds a "received" header field parameter to that Via header field value. This parameter contains the source IP address from which the packet was received.
    When the P-CSCF receives a 200 (OK) response to a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:
    1. store an association between the IP source address and port of the initial REGISTER request and the public user identities found in the P-Associated-URI header field value and associate them to the public user identity under registration;
    2. store an association between the IP source address and port of the initial REGISTER request the default public user identity for use with procedures for the P-Asserted-Identity header field. The default public user identity is the first on the list of URIs present in the P-Associated-URI header field;
    3. if the P-CSCF adds a "received" header field parameter and UDP is being used, the P-CSCF shall also add an "rport" Via header field parameter with the IP source port of the received REGISTER request; and
    4. insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7.
    Up

    5.2.2.7  P-CSCF reconfigured to not accept registrations |R10|  p. 181

    If the P-CSCF has been reconfigured to not accept initial registrations and reregistrations and to redirect incoming registrations to another P-CSCF, on recepetion of a REGISTER request the P-CSCF shall return a 305 (Use Proxy) response.
    Up

    Up   Top   ToC