1. Analysis of Use of Separate Identity Header for SIP RPH Signing
ATIS PTSC & IPNNI Task Force
AMOC May 8, 2017
Analysis of Use of Separate Identity Header for SIP RPH Signing
Ray P. Singh
formerly Applied Communication Sciences

2. Outline Background Open Issue and Objective Assumptions Pro and Con
Conclusions and Recommendation

3. Background
Proposal to define a STIR PASSPorT extension to sign the RPH namespace parameters was discussed at the February 2017 meeting:
IPNNI R1: Baseline Text for the Standard on Signature-based Handling of SIP RPH Assertion using Tokens
IPNNI : Draft proposal [draft-tbd-stir-rph-01] for PASSporT extension

4. Open Issue and Objective
Need to determine whether RPH namespace claims
Should be part of the same identity header used for Calling Party Number (CPN) signing, or
Should be included in a separate identity header
Objective
Provide an analysis of the above open issue and recommend a path forward

5. Not all Service Providers are concerned with RPH Signing
Assumptions
Not all Service Providers are concerned with RPH Signing
Small number of authorized Service Providers of GETS and WPS
Some NS/EP Priority Communications involve legitimate replacement of initially signaled CPN
End-to-end NS/EP Priority Communications may traverse both NS/EP Service Providers and other service providers networks

6. Use of Same Identity Header for CPN and SIP RPH Claims
Pros and Cons
Use of Same Identity Header for CPN and SIP RPH Claims
Pros
Cons
Protocol efficiency of using a single identity header (i.e., protocol overhead advantages)
The same identity header would contain claims that are unrelated from an application service perspective:
Claims associated with CPN (e.g., used for display application services)
Claims associated with RPH name spaces (e.g., used for GETS and WPS security)
No need to define a separate identity header for RPH namespace signing
Having both types of claims in the same identify header may result in unnecessary complexity in terms of specifying the processing, rules and procedures for handling both CPN and RPH name space claims. Not all service providers will be concerned with both types of claims. For example, service providers that are not providers of NS/EP Priority Services may not be concerned with “ets” and “wps” namespace claims. Having both CPN and RPH claims in the same identity header will be unnecessary complicated for service providers not concerned with RPH namespaces.
May have operational advantage for NS/EP Priority calls involving CPN modifications (e.g., NT calls)
Added complexity given that RPH namespaces used to support many different application services (e.g., IETF defines namespaces for “DSN,” “DRSN, ” “Q735,” “ETS” and “WPS,” and “MCPTT”)
The processing of CPN and SIP RPH claims may need to be processed in different parts of a given service provider network. For example, a network provider may need to process the RPH claim at the entry point of an IPNNI (i.e., to decide whether to provide priority). In the case of a CPN claim, the claim may only need to be processed at a point close to the terminating UE to determine Display information.

7. Use of Different Identity Header for CPN and SIP RPH Claims
Pros and Cons
Use of Different Identity Header for CPN and SIP RPH Claims
Pros
Cons
Clean separation of claims used for different application services:
Claims associated with CPN (e.g., CPN Display)
Claims associated with RPH name spaces (e.g., GETS and WPS)
Will need to define identity header for RPH namespace signing
The processing and use of CPN claims versus RPH namespace claims can be defined independently in terms of the supported application services (e.g., Display applications versus NS/EP applications).
Less complexity in terms of specifying the rules and procedures for handling both CPN and RPH name space claims.
Additional protocol overhead for service providers that need to add both RPH and CPN claims
Different Services using RPH namespaces defined in IETF can evolve and use RPH signing independent of CPN signing: “DSN,” “DRSN, ” “Q735,” “ETS” and “WPS” and MCPTT
Allows more flexible network design for the processing of CPN and SIP RPH claims in different parts of a given service provider network. For example, network design to process RPH claims at IPNNI entry points and CPN claims at points close to terminating UEs.

8. Conclusions and Recommendation
Using the same identity header for both CPN and RPH Signing will be complicated in terms of processing, rules and procedures
Using a separate identity header for SIP RPH Signing allows clean separation
Solutions for SIP RPH Signing can be specified and designed independent of CPN Signing
Processing of CPN Signing and SIP RPH kept separate including processing of NS/EP Priority Service (e.g., NT Calls) involving CPN replacement
Allows downstream providers and network nodes concern with only CPN signing to act on identity header for CPN signing independently
Allows downstream providers and network nodes concern only with SIP RPH to act on identity header for SIP RPH signing independently
Recommendation
It is recommended that a separate identity header be defined for SIP RPH Signing

9. TRANSFORMATIVE RESEARCH