Via header field parameter to indicate received realm

When SIP sessions are established between networks belonging to different operators, or between interconnected networks belonging to the same operator (or enterprise), the SIP requests might traverse transit network. Such transit networks might provide different kind of services. In order to do that, a transit network often needs to know to which operator (or enterprise) the adjacent upstream network, from which the SIP session initiation request is received, belongs. This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "received-realm", which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received, using a network realm value associated with the adjacent network. NOTE: As the adjacent network can be an enterprise network, an Inter Operator Identifier (IOI) cannot be used to identity the network, as IOIs are not defined for enterprise networks. The following sections describe use-case where the information is needed.

The 3rd Generation Partnership Project (3GPP) TS 23.228 specifies how an IP Multimedia Subsystem (IMS) network can be used to provide transit functionality. An operator can use its IMS network to provide transit functionality e.g. to non-IMS customers, to enterprise networks, and to other network operators. The transit network operator can provide application services to the networks for which it is providing transit functionality. Transit application services are typically not provided per user basis, as the transit network does not have access to the user profiles of the networks for which the application services are provided. Instead, the application services are provided per served network. When a SIP entity that provides application services (e.g. an Application Server) within a transit network receives a SIP request, in order to apply the correct services it needs to know the adjacent upstream network from which the SIP request is received.

A transit network operator normally interconnects to many diferent operators, including other transit network operators, and provides transit routing of SIP requests received from one operator network towards the destination. The destination can be within an operator network to which the transit network operator has a direct interconnect, or within an operator network that only can be reached via one or more interconnected transit operators. For each customer, i.e. interconnected network operator for which, the transit network operator routes SIP requests towards the requested destination a set of transit routing polices are defined. These policies are used to determine how a SIP request shall be routed towards the requested destination to meet the agreement the transit network operator has with its customer. When a SIP entity that performs the transit routing functionality receives a SIP request, in order to apply the correct set of transit routing policies, it needs to know from which of its customers, i.e. adjacent upstream network, the SIP request is received.

The mechanism defined in this specification MUST only be used by SIP entities that are able to verify from which adjacent upstream network a SIP request is received. The mechanism for verifying from which adjacent upstream network a SIP request is received is outside the scope of this specification.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 .

SIP entity: SIP User Agent (UA), or SIP proxy, as defined in RFC 3261. Adjacent upstream SIP network: The adjacent SIP network in the direction from which a SIP request is received. Network entry point: A SIP entity on the border of network, which receives SIP requests from adjacent upstream networks. Inter Operator Identifier (IOI): A globally unique identifier to correlate billing information generated within the IP Multimedia Subsystem (IMS). JWT: JSON Web Token, as defined in RFC 7519.

The Via 'received-realm' header field parameter value is represented as a JSON Web Token (JTW) . The JWT payload contains SIP header filed values, and the value representing the adjacent network. The procedures for encoding the JWT and calculating the signature are defined in .

The following header parameters MUST be included in the JWT. The "typ" parameter MUST have a "JWT" value. The "alg" parameter MUST have the value of the algorithm used to calculate the JWT signature. NOTE: Operators need to agree on the set of supported algorithms for calculating the JWT signature.

The follwoing payload claims MUST be included in the JWT. The "adjacent_network" claim has the value representing the adjacent network. The "sip_from_tag" claim has the value of the From 'tag' header field parameter of the SIP message. The "sip_date" claim has the value of the Date header field in the SIP message. The "sip_callid" claim has have value of the Call-ID header field in the SIP message. The "sip_cseq_num" claim has the numeric value of the CSeq header field in the SIP message. the "sip_via_branch" claim has value of the Via branch header field parameter of the Via header field, in the SIP message, to which the received-realm header parameter is attached.

This section describes the syntax extensions to the ABNF syntax defined in , by defining a new Via header field parameter, "received-realm". The ABNF defined in this specification is conformant to RFC 5234 . "EQUAL", "LDQUOT", "RDQUOT" and "ALPHA" are defined in . "DIGIT" is defined in .

This section describes how a SIP entity, acting as an entry point to a network, uses the "received-realm" Via header field parameter.

When a SIP entity, acting as a network entry point, forwards a SIP request, or initiates a SIP request on its own (e.g. a PSTN gateway), the SIP entity adds a Via header field to the SIP request, according to the procedures in RFC 3261 . In addition, if the SIP entity is able to assert the adjacent upstream network, and if the SIP entity is aware of a network realm value defined for that network, the SIP entity can add a "received-realm" Via header field parameter, conveying the network realm value, to the Via header field added to the SIP request. When the SIP entity adds a "received-realm" Via header field parameter to a SIP request, it MUST also calculate a Hash-based message authentication code (HMAC) value from the parameter value, using a secret key which is shared between the SIP entity and any SIP entity which will use the parameter value. The HMAC is then added to the parameter. When the receiver decodes the JWT, it MUST compare the JWT claims with the corresponding SIP header field information. If there is a mismatch, the receiver MUST discard the received-realm header field parameter.

When a SIP entity receives a Via 'received-network' header field parameter, and intends to perform actions based on the header field parameter value, it MUST first check whether the values of the JWT claims representing SIP header field values match the associated SIP header field values within the SIP request. If the values of the JWT claims representing SIP header field values do not match the values of the associated SIP header field values the SIP entity MUST discard the adjacent network information present in the JWT. The SIP entity MAY take also take additional actions (e.g. rejecting the SIP request) based on local policy.

Via: IP_UA - INVITE ----------------------------> Via: IP_TEP; received-realm="eyJhbG.eyJpc3.03f329" Via: IP_UA; received=IP_UA <- 200 OK ---------------------------- Via: IP_TEP; received-realm="eyJhbG.eyJpc3.03f329" Via: IP_UA; received=IP_UA <- 200 OK------ Via: IP_UA; received=IP_UA ]]>

This specification defines a new Via header field parameter called received-realm in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by . The syntax is defined in . The required information is:

This specification defines new JSON Web Token claims in the "JSON Web Token Claims" sub-registry as per the registry created by . Claim Name: "adjacent_network" Claim Descritpoin: Adjacent network from where a SIP request is received Change Controller: IESG Specification Document(s): RFC XXXX Claim Name: "sip_from_tag" Claim Descritpoin: SIP From tag header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_date" Claim Descritpoin: SIP Date header field value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_callid" Claim Descritpoin: SIP Call-Id header field value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_cseq_num" Claim Descritpoin: SIP CSeq numeric header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_via_branch" Claim Descritpoin: SIP Via branch header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261

As the received-realm Via header field parameter can be used to trigger applications, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity. The operator MUST change the key on a frequent basis. The operator also needs to take great care in ensuring that the key used to calculate the JWT signature value is only known by the network entry point adding the received-realm Via header field parameter to a SIP message and the entities that use the parameter value. A SIP entity MUST NOT use the adjacent network information if the values of the JWT claims representing SIP header field values do not match the values of the associated SIP header field values. A SIP entity MUST use different key values for each parameter value that it recognizes and use to trigger actions.

Thanks to Adam Roach and Richard Barnes for providing comments and feedback on the document.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-dispatch-received-realm-01 Define received-realm parameter value as a JSON Web Token (JWT). Changes from draft-holmberg-dispatch-received-realm-00 New version due to expiration of previous version. Changes from draft-holmberg-received-realm-04 Changed IETF WG from sipcore do dispatch. HMAC value added to the parameter. Changes from draft-holmberg-received-realm-03 New version due to expiration. Changes from draft-holmberg-received-realm-02 New version due to expiration. Changes from draft-holmberg-received-realm-01 New version due to expiration. Changes from draft-holmberg-received-realm-00 New version due to expiration.