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

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.

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

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

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

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

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

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

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

Thank You