Session Initiation Protocol (SIP) Via header field parameter to indicate received realm
EricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.comChina Mobile No.32 Xuanwumen West Street Xicheng District 100053BeijingP.R. Chinajiangyi@chinamobile.com
Transport
SIPCORE Working GroupSIPViatransitrealm
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.
When Session Initiation Protocol (SIP)
sessions are established between networks belonging to different
operators, or between interconnected networks belonging to the same operator
(or enterprise), the SIP requests associated with the session might
traverse transit networks.
Such transit networks might provide different kinds of services. In order
to provide such services, 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-cases 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 on a 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 different
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. Such mechanism might be
based for instance on receiving the SIP request on an authenticated Virtual Private
Network (VPN), receiving the SIP request on a specific IP address, or on a specific
network access.
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).
JWS: JSON Web Signature, as defined in .
The Via 'received-realm' header field parameter value is represented as a
combination of an operator identifier, whose value represents the adjacent
network, and a serialized JSON Web Signature (JWS) .
The JWS Payload consists of the operator identifier and other SIP information element values.
The procedures for encoding the JWS and calculating the signature are defined in
. As the JWS Payload
information is found in other SIP information elements, the JWS Payload is not attached
to the serialized JWS conveyed in the header field parameter, as described in Appendix F of
. The operator identifier and
the serialized JWS are separated using a colon character.
The Operator Identifier is a token value that represents the adjacent operator. The
scope of the value is only within the network that inserts the value.
The Operator Identifier value is case-insensitive.
The following header parameters MUST be included in the JWS.
The "typ" parameter MUST have a "JWT" value.The "alg" parameter MUST have the value of the algorithm used to calculate the JWS.
NOTE: Operators need to agree on the set of supported algorithms for calculating the JWT signature.
NOTE: The "alg" parameter values for specific algorithms are listed in the IANA JSON Web Signature
and Encryption Algorithms sub-registry of the JSON Object Signing and Encryption (JOSE) registry.
Operators need to use algorithms for which an associated "alg" parameter value has been
registered. The procedures for defining new values are defined in .
The following claims MUST be included in the JWS Payload:
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,
encoded in JSON NumericDate format . 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 field parameter is attached. the "sip_via_opid" claim has value of the operator identifier part of the Via received-realm
header field parameter of the Via header field, in the SIP message, to which the received-realm
header field parameter is attached.
As the JWS Payload is not carried in the received-realm parameter,
in order to make sure that the sender and the receiver construct the
JWS Payload object in the same way, the JSON representation of the
JWS Payload object it MUST be computed as follows:
All claims MUST be encoded using lower case characters.The claims MUST be in the same order as listed in
[].All claims except "sip_date" MUST be encoded as StringOrURI JSON
string value .The "sip_date" claim MUST be encoded as a JSON NumericDate value
.The JWS Payload MUST follow the rules for the construction of the
thumbprint of a JSON Web Key (JWK) as defined in
Section 3
Step 1 only.
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 as the operator identifier ()
part of the header field parameter, to the Via header field added to the SIP request.
In addition the SIP entity MUST also calculate a JWS ()
and add the calculated JWS Header and JWS Signature as the jws part of the Via 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 re-calculate the JWS and check whether the result
matches the JWS received. If there is not a match, the SIP entity MUST discard the received 'received-network'
header field parameter. The SIP entity MAY take also take additional actions (e.g., rejecting the SIP request)
based on local policy.
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: "sip_from_tag" Claim : SIP From tag header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_date" Claim Description: SIP Date header field value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_callid" Claim Description: SIP Call-Id header field value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_cseq_num" Claim Description: SIP CSeq numeric header field parameter value Change Controller: IESG Specification Document(s): RFC XXXX, RFC 3261 Claim Name: "sip_via_branch" Claim Description: 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 received-realm Via header field parameter is inserted, signed,
verified and consumed within an operator network. The operator MUST
discard parameters received from another network, and the parameter
MUST only be inserted by SIP entities that are able to verify from
which adjacent upstream network a SIP request is received.
The operator also needs to take great care in ensuring that the key used
to calculate the JWS signature value is only known by the network entities
signing and adding the JWS signature to the received-realm Via
header field parameter of a SIP message, and to network entities
verifying and consuming the parameter value.
The operator MUST use a key management policy that protects agains
unauthorised access to the stored keys within nodes where they keys
associated with the JWS signature are stored, and that protects against
crypto analysis attacks using captured data sent on the wire.
A SIP entity MUST NOT use the adjacent network information if
there is a mismatch between the JWS signature received in the SIP header
field and the JWS signature calculated by the receiving entity.
Generic security considerations for JWS are defined in
.
Thanks to Adam Roach and Richard Barnes for providing comments and
feedback on the document. Francis Dupoint performed the Gen-ART
review.
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-dispatch-received-realm-10
Changes based on IESG review.Changes based on SecDIR review.Changes based on IANA Service Operator review.
Changes from draft-holmberg-dispatch-received-realm-09
Reference to RFC 2104 removed.
Changes from draft-holmberg-dispatch-received-realm-08
Editorial fixed based on Gen-ART review.Editorial fixes based on comments from IANA Service Operator review.- Quotes removed from sip_date value.
Changes from draft-holmberg-dispatch-received-realm-07
Editorial changes.
Changes from draft-holmberg-dispatch-received-realm-06
Changes based on AD review by Ben Campbell:- operator-id added to JSON Payload
Changes from draft-holmberg-dispatch-received-realm-05
Editorial fixes.
Changes from draft-holmberg-dispatch-received-realm-04
JSON serialization procedure added.
Changes from draft-holmberg-dispatch-received-realm-03
ABNF correction.
Changes from draft-holmberg-dispatch-received-realm-02
JWT replaced with JWS.Appendix F of RFC 7515 applied.
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.
IP Multimedia Subsystem (IMS); Stage 2
3GPP