1. SIP RPH Signing Use Cases
October 23, 2018
ATIS IPNNI Task Force
SIP RPH Signing Use Cases
Ray P. Singh
formerly Applied Communication Sciences

2. Overview Purpose and Objective Assumptions
The objective is to discuss examples illustrating use of IETF RFC 8443 for signing SIP RPH in support of NS/EP NGN-PS across IPNNIs for the purpose of
Vetting these use cases
Identifying and reaching mutual agreement on implied requirements
Assumptions
SIP RPH signing is performed by the authenticating/authorizing NS/EP Service Provider (e.g., authorized provider of WPS, GETS and NGN-PS) before it is sent across an IPNNI
Normal NS/EP NGN-PS is used to authenticate/authorize the user (i.e., WPS and GETS verifications) and then SIP RPH signing is used to attest that the NS/EP NGN-PS call was authorized
SIP RPH signing does not change or modify NS/EP NGN-PS call processing, signaling and routing procedures, it simply provides a security tool for a receiving provider to determine if the SIP RPH is trusted
If any information of a received signed SIP RPH is modified as part of NS/EP NGN-PS processing by an authorized NS/EP NGN-PS provider (e.g., change of TN or user priority level), the original token is replaced with a new signature for the new SIP RPH.

3. RPH Signing Use Case Examples
Description 1
Basic Access Number (AN) Call
Originating LEC routes AN call to NS/EP NGN-PS Service Provider (SP) which is then routed to terminating network 2
Basic Feature Code (FC) Call
Originating WPS SP routes basic FC call via Transit NS/EP NGN-PS Service Provider (SP) to terminating network 3
FC+AN Call
Originating WPS SP routes FC+AN dialed call to NS/EP NGN-PS SP (IXC) and call is then routed to terminating network 4
GETS-NT or AN+GETS-PDN Origination in LEC
Originating LEC routes GETS-NT or AN+GETS-PDN call to NS/EP NGN-PS Service Provider (SP) and call is then routed to terminating network 5
FC+GETS-NT or FC+AN+GETS-PDN Origination
Originating WPS SP routes GETS-NT or AN+GETS-PDN call to NS/EP NGN-PS Service Provider (SP) and call is then routed to terminating network 6
Call Termination in non-NS/EP NGN-PS Network
NS/EP NGN-PS call (AN, FC, FC+AN, GETS-NT, AN+GET-PDN, FC+GETS-NT, FC+AN+GETS-PDN) with signed RPH is terminated in a non-NS/EP NGN-PS SP network
Note: For simplicity only the SIP Invites going across IPNNIs are shown in the following illustrative diagrams

4. Use Case 1: AN Routed to NS/EP NGN-PS Provider
Originating LEC
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider UE
1. Invite
2. Invite
ppt [rph:"auth“]
ets.x wps.y
ets.x
3. Invite
4. Invite
5. Invite
Originating LEC
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider
LEC is not NGN-PS Service Provider:
GETS-AN origination identified as NS/EP based on dialed digits and routed to NS/EP NGN-PS Service Provider
RPH is NOT signed because user has not yet been authenticated
NS/EP Service Provider:
Performs normal NS/EP NGN-PS processing (including PIN validation*) and RPH ets and wps name spaces are populated with provisioned values
RPH of outgoing SIP Invite is signed using PASSPorT extension and signature is included in a SIP identity header.
*Note: PIN validation viewed as RPH-AS function (i.e., user authentication)
Transit NS/EP NGN-PS Provider:
May validate the signed RPH to determine whether Invite is forwarded within transit network with RPH
If validation is successful, Invite is forwarded within transit network with the RPH
If validation is not successful decision to (a) strip RPH or (b) leave RPH is based on carrier local policy
Terminating NS/EP Service Provider:
Validates signed RPH
If validation is successful, Invite is forwarded within terminating network with RPH
If validation is not successful, decision to (a) strip RPH or (b) keep RPH is based on carrier local policy

5. Use Case 2: Basic FC+DN Origination
Originating WPS
Transit NS/EP NGN-PS Provider
Terminating Network UE
1. Invite
2. Invite
ets.x wps.y
3. Invite
4. Invite
ppt [rph:"auth“]
ppt [rph:"auth“]
Originating WPS
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Service
Handset subscribed for NS/EP NGN-PS and is registered:
User initiates FC call (i.e., *272+destination number)
SP performs normal NS/EP NGN-PS processing (i.e., subscription validation) and populates ets and wps name spaces with provisioned values
RPH is signed by WPS SP because the WPS subscription was validated (i.e., viewed as authentication of the user authorization to make WPS call)
Transit NS/EP NGN-PS Provider:
May validate the signed RPH to determine whether Invite is forwarded within transit network with RPH
If validation is successful, Invite is forwarded within transit network with the RPH
If validation is not successful decision to (a) strip RPH or (b) leave RPH is based on carrier local policy
Terminating NS/EP Service Provider:
Validates signed RPH
If validation is successful, Invite is forwarded within terminating network with RPH
If validation is not successful, decision to (a) strip RPH or (b) keep RPH is based on carrier local policy

6. Use Case 3: FC+AN Origination
Originating WPS
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider UE
1. Invite
2. Invite
ppt [rph:"auth“]
ets.x wps.y2
ets.x wps.y1
3. Invite
4. Invite
5. Invite
Note: There may be a Transit provider between the WPS and Originating NS/EP NGN Provider
Originating WPS
Originating NS/EP NGN-PS (IXC) Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider
Handset subscribed for NS/EP NGN-PS and is registered:
User initiates FC+AN call (i.e., *272+NCS-GETS)
SP performs normal NS/EP NGN-PS processing (i.e., WPS subscription validation*) and populates ets and wps name spaces with provisioned values
RPH is signed by WPS SP
*Note: subscription validation viewed as RPH-AS function (i.e., device authentication)
NS/EP NGN-PS Provider:
Performs normal NS/EP NGN-PS processing (including PIN validation*)
RPH ets and wps name spaces are populated with provisioned values where the wps value is set to the user priority
RPH of outgoing SIP Invite is signed using PASSPorT extension and included in a SIP identity header since RPH was changed
*Note: PIN validation viewed as RPH-AS function (i.e., user authentication)
Transit NS/EP NGN-PS Provider:
May validate the signed RPH to determine whether priority is provided within transit network
Signed RPH passed unchanged
Terminating WPS Provider:
Validates signed RPH
If validation is successfully, Invite is forwarded within Terminating network with the RPH
If validation is not successful decision to (a) strip RPH or (b) keep RPH is based on carrier local policy

7. Use Case 4: GETS-NT or AN+GETS-PDN Call Origination in LEC
Originating LEC
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider UE
1. Invite
2. Invite
ppt [rph:"auth“]
ets.x wps.y1
ets.x
3. Invite
4. Invite
5. Invite
Originating LEC
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider
LEC is not NGN-PS Service Provider:
User initiates GETS-NT or AN+GETS-PDN call
Call identified as NS/EP based on dialed digits and routed to NS/EP NGN-PS Service Provider with RPH
RPH is NOT signed because user authorization has not yet been authenticated
NS/EP Service Provider:
Performs normal NS/EP NGN-PS processing, including PIN validation, translation and Caller-ID modification for anonymity and the RPH ets and wps namespaces are populated with provisioned values where the wps value is set to the user priority
RPH of outgoing SIP Invite is signed using PASSPorT extension and included in a SIP identity header
*Note: PIN validation viewed as RPH-AS function (i.e., user authentication)
Transit NS/EP NGN-PS Provider:
May validate the signed RPH to determine whether Invite is forwarded within transit network with RPH
If validation is successfully, Invite is forwarded within transit network with the RPH
If validation is not successful decision to (a) strip RPH or (b) keep RPH is based on carrier local policy
Terminating NS/EP Service Provider:
Validates signed RPH
If validation is successful, Invite is forwarded within terminating network with RPH
If validation is not successful, decision to (a) strip RPH or (b) keep RPH is based on carrier local policy

8. Use Case 5: FC+GETS-NT or FC+AN+GETS-PDN Call Origination
Originating WPS
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating WPS UE
1. Invite
2. Invite
ppt [rph:"auth“]
ets.x wps.y2
ets.x wps.y1
3. Invite
4. Invite
5. Invite
ppt [rph:"auth“]
Note: There may be a Transit provider between the WPS and Originating NS/EP NGN Provider
Originating WPS SP
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating NS/EP NGN-PS Provider
Handset subscribed for NS/EP NGN-PS and is registered:
User initiates FC call (i.e., *272)
SP performs normal NS/EP NGN-PS processing (i.e., subscription validation) and populates ets and wps name spaces with provisioned values
RPH is signed by WPS SP because the WPS subscription was validated (i.e., viewed as authentication of the user authorization to make WPS call)
NS/EP Service Provider:
Performs normal NS/EP NGN-PS processing, including PIN validation*, translation and Caller-ID modification for anonymity and the RPH ets and wps namespaces are populated with provisioned values where the wps value is set to the user priority
RPH of outgoing SIP Invite is signed using PASSPorT extension and included in a SIP identity header
*Note: PIN validation viewed as RPH-AS function (i.e., user authentication)
Transit NS/EP NGN-PS Provider:
May validate the signed RPH to determine whether Invite is forwarded within transit network with RPH
If validation is successful, Invite is forwarded within transit network with the RPH
If validation is not successful decision to (a) strip RPH or (b) keep RPH is based on carrier local policy
Terminating NS/EP Service Provider:
Validates signed RPH
If validation is successful, Invite is forwarded within terminating network with RPH
If validation is not successful, decision to (a) strip RPH or (b) keep RPH is based on carrier local policy

9. Use Case 6:Call Termination in non-NS/EP NGN-PS Network
Originating LEC
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating LEC UE
1. Invite
2. Invite
ppt [rph:"auth“]
ets.x wps.y
ets.x
3. Invite
4. Invite
5. Invite
Originating LEC
Originating NS/EP NGN-PS Provider
Transit NS/EP NGN-PS Provider
Terminating LEC
LEC is not NGN-PS Provider:
Call identified as NS/EP NGN-PS based on dialed digits and routed to NS/EP NGN-PS Service Provider
RPH is NOT signed because user authorization has not yet been authenticated
NS/EP NGN-PS Provider:
Performs normal NS/EP NGN-PS processing (including PIN validation*) and populates SIP RPH ets and wps namespaces with provisioned values
RPH of outgoing SIP Invite is signed using PASSPorT extension and included in a SIP identity header.
*Note: PIN validation viewed as RPH-AS function (i.e., user authentication)
Transit NS/EP NGN-PS Provider:
May validate the signed RPH to determine whether Invite is forwarded within transit network with RPH
If validation is successful, Invite is forwarded within transit network with the RPH
If validation is not successful decision to (a) strip RPH or (b) keep RPH is based on carrier local policy
Terminating LEC is not NS/EP NGN-PS Provider:
LEC not required to provided priority treatment therefore validation of signed RPH not required

10. Thank You