wdiff rfc8055.original rfc8055.txt

SIPCORE Working Group
Internet Engineering Task Force (IETF) C. Holmberg
Internet-Draft
Request for Comments: 8055 Ericsson
Intended status:
Category: Standards Track J. Y. Jiang
Expires: June 6, 2017
ISSN: 2070-1721 China Mobile
December 3, 2016
January 2017

Session Initiation Protocol (SIP) Via header field parameter Header Field Parameter
to indicate
received realm
draft-holmberg-dispatch-received-realm-12.txt Indicate Received Realm

Abstract

This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter, "received-realm", '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, received by using a
network realm value associated with the adjacent network.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on June 6, 2017.
http://www.rfc-editor.org/info/rfc8055.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Use-Case: Use Case: Transit Network Application Services . . . . . 3
1.3. Use-Case: Use Case: Transit Network Routing . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Via 'received-realm' header field parameter Header Field Parameter . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Operator Identifier . . . . . . . . . . . . . . . . . . . 5
5.3. JWS Header . . . . . . . . . . . . . . . . . . . . . . . 5
5.4. JWS Payload . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. JWS Serialization . . . . . . . . . . . . . . . . . . . . 7 6
5.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
5.6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 7
5.7. Example . . . . . . . . . . . Example: SIP Via Header Field . . . . . . . . . . . . . . 8
6. User Agent and Proxy behavior Behavior . . . . . . . . . . . . . . . . 8
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Behavior of a SIP entity acting Entity Acting as a network entry point Network Entry Point 8
6.3. Behavior of a SIP entity consuming Entity Consuming the received-network
value 'received-realm'
Value . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8
7. Example . . . . . . . . . . . . . . . . . Example: SIP INVITE Request and Response . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. 'received-realm' Via header field parameter Header Field Parameter . . . . . . . 9
8.2. JSON Web Token Claims Registration . . . . . . . . . . . 10 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. Change Log References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . 13
12.1. Normative References . . . . . . . . . . . 11
Acknowledgements . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 12

1. Introduction

1.1. General

When Session Initiation Protocol (SIP) [RFC3261] sessions are
established between networks belonging to different operators, 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) SIP Via header field parameter, "received-realm",
'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, received by 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 identify the network, as network
because IOIs are not defined for enterprise networks.

The following sections describe use-cases use cases where the information is
needed.

1.2. Use-Case: Use Case: Transit Network Application Services

The 3rd Third Generation Partnership Project (3GPP) TS 23.228
[TS.3GPP.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 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.

1.3. Use-Case: Use Case: Transit Network Routing

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,
interconnect or within an operator network that only can be reached
via one or more interconnected transit operators.

For each customer, i.e., customer (i.e., interconnected network operator, operator) for which
the transit network operator routes SIP requests towards the
requested destination, a set of transit routing polices policies 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., customers (i.e.,
adjacent upstream network, network) the SIP request is received.

2. Applicability

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 a mechanism might be based on, for instance on instance, 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.

3. Conventions

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
[RFC2119].

4. Definitions

SIP entity: A 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 the 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: A JSON Web Signature, as defined in [RFC7515].

5. Via 'received-realm' header field parameter Header Field Parameter

5.1. General

The Via 'received-realm' header field parameter value is represented
as a combination of an operator identifier, identifier whose value represents the
adjacent network, network and a serialized JSON Web Signature (JWS) [RFC7515].
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 [RFC7515]. As the JWS Payload information is found in
other SIP information elements, the JWS Payload is detached from the
serialized JWS conveyed in the header field parameter, as described
in Appendix F of [RFC7515]. The operator identifier and the
serialized JWS are separated using a colon character.

5.2. Operator Identifier

The Operator Identifier 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 operator identifier value is case-insensitive. case insensitive.

5.3. JWS Header

The following header parameters MUST be included in the JWS.

o The "typ" parameter MUST have a "JWT" value.

o 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 [RFC7518].

Example:

{
"typ":"JWT",
"alg":"HS256"
}

5.4. JWS Payload

The following claims MUST be included in the JWS Payload:

o The "sip_from_tag" claim has the value of the From 'tag' header
field parameter of the SIP message.

o The "sip_date" claim has the value of the Date header field in the
SIP message, encoded in JSON NumericDate format [RFC7519].

o The "sip_callid" claim has have the value of the Call-ID header field
in the SIP message.

o The "sip_cseq_num" claim has the numeric value of the CSeq header
field in the SIP message.

o the The "sip_via_branch" claim has the value of the Via branch header
field parameter of the Via header field, in the SIP message, to
which the received-realm 'received-realm' header field parameter is attached.

o the The "sip_via_opid" claim has the value of the operator identifier
part of the Via received-realm 'received-realm' header field parameter of the Via
header field, in the SIP message, to which the received-realm 'received-realm'
header field parameter is attached.

Example:

{
"sip_from_tag":"1928301774",
"sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159",
"sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"
}

5.5. JWS Serialization

As the JWS Payload is not carried in the received-realm '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:

o All claims MUST be encoded using lower case lowercase characters.

o The claims MUST be in the same order as listed in [Section 5.4]. Section 5.4.

o All claims except "sip_date" MUST be encoded as StringOrURI JSON
string value [RFC7519].

o The "sip_date" claim MUST be encoded as a JSON NumericDate value
[RFC7519].

o The JWS Payload MUST follow the rules for the construction of the
thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3 3, Step 1 only.
only, of [RFC7638].

Example:

{"sip_from_tag":"1928301774","sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159","sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"}

NOTE: Line breaks are for display purpose only

{"sip_from_tag":"1928301774","sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com","sip_cseq_num":"314159",
"sip_via_branch":"z9hG4bK776asdhds","sip_via_opid":"myoperator"} purposes only.

5.6. Syntax

5.6.1. General

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

5.6.2. ABNF

via-params =/ received-realm
received-realm = "received-realm" EQUAL LDQUOT op-id COLON jws RDQUOT
op-id = token
jws = header ".." signature
header = 1*base64-char
signature = 1*base64-char
base64-char = ALPHA / DIGIT / "/" / "+"

EQUAL, COLON, token, LDQUOT, RDQUOT, ALPHA ALPHA, and DIGIT are as defined
in [RFC3261].

NOTE: The two adjacent dots in the jws 'jws' part is are due to the detached
payload being replaced by an empty string [RFC7515].

5.7. Example Example: SIP Via Header Field

Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1N..
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"

NOTE: Line breaks are for display purpose only purposes only.

6. User Agent and Proxy behavior Behavior

6.1. General

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

6.2. Behavior of a SIP entity acting Entity Acting as a network entry point Network Entry Point

When a SIP entity, entity acting as a network entry point, point forwards a SIP
request,
request or initiates a SIP request on its own (e.g., a PSTN Public
Switched Telephone Network (PSTN) gateway), the SIP entity adds a Via
header field to the SIP request, according to the procedures in RFC
3261 [RFC3261]. In addition, if the SIP entity is able to assert the
adjacent upstream network, 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"
'received-realm' Via header field
parameter, parameter conveying the network
realm value as the operator identifier (Section 5.2) part of the
header field parameter, to the Via header field added to the SIP
request.

In addition addition, the SIP entity MUST also calculate a JWS (Section 5.4)
and add the calculated JWS Header and JWS Signature as the jws 'jws' part
of the Via header field parameter.

6.3. Behavior of a SIP entity consuming Entity Consuming the received-network value 'received-realm' Value

When a SIP entity receives a Via 'received-network' 'received-realm' header field
parameter,
parameter and intends to perform actions based on the header field
parameter value, it MUST first re-calculate recalculate 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' 'received-realm' header field
parameter. The SIP entity MAY take also take additional actions (e.g.,
rejecting the SIP request) based on local policy.

7. Example Example: SIP INVITE Request and Response

This section shows an example of a SIP INVITE request and the
associated response, which contains a Via header field (inserted into
the request and removed from the response by the T_EP SIP proxy) with
a 'received-realm' header field parameter.

Operator 1 T_EP T_AS

- INVITE ------>
Via: SIP/2.0/UDP IP_UA
-- INVITE ---------------------------->
Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh
bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW
1gFWFOEjXk"
Via: SIP/2.0/UDP IP_UA; received=IP_UA

<- 200 OK ----------------------------
Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh
bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW
1gFWFOEjXk"
Via: SIP/2.0/UDP IP_UA; received=IP_UA

<- 200 OK------
Via: SIP/2.0/UDP IP_UA; received=IP_UA

8. IANA Considerations

8.1. 'received-realm' Via header field parameter Header Field Parameter

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

Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via received-realm No RFCXXXX RFC 8055

8.2. JSON Web Token Claims Registration

This specification defines new JSON Web Token claims in the "JSON Web
Token Claims" sub-registry as per the registry created by [RFC7519].

Claim Name: "sip_from_tag" sip_from_tag
Claim : Description: SIP From tag header field parameter value
Change Controller: IESG

Specification Document(s):
Reference: RFC XXXX, 8055, RFC 3261

Claim Name: "sip_date" sip_date
Claim Description: SIP Date header field value
Change Controller: IESG

Specification Document(s):
Reference: RFC XXXX, 8055, RFC 3261

Claim Name: "sip_callid" sip_callid
Claim Description: SIP Call-Id header field value
Change Controller: IESG

Specification Document(s):
Reference: RFC XXXX, 8055, RFC 3261

Claim Name: "sip_cseq_num" sip_cseq_num
Claim Description: SIP CSeq numeric header field parameter value
Change Controller: IESG

Specification Document(s):
Reference: RFC XXXX, 8055, RFC 3261

Claim Name: "sip_via_branch" sip_via_branch
Claim Description: SIP Via branch header field parameter value
Change Controller: IESG
Specification Document(s):
Reference: RFC XXXX, 8055, RFC 3261

9. Security Considerations

As the received-realm '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 'received-realm' Via header field parameter is inserted, signed,
verified
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 Signature value is only known by the
network entities signing and adding the JWS signature Signature to the
received-realm
'received-realm' Via header field parameter of a SIP message, message and to
network entities verifying and consuming the parameter value.

The operator MUST use a key management policy that protects agains
unauthorised against
unauthorized access to the stored keys within nodes where they the keys
associated with the JWS signature Signature are stored, stored and that protects
against crypto analysis cryptoanalysis 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 Signature received in the SIP header
field and the JWS signature Signature calculated by the receiving entity.

Generic security considerations for JWS are defined in [RFC7515].

10. Acknowledgments

Thanks to Adam Roach and Richard Barnes for providing comments and
feedback on the document. Francis Dupoint performed the Gen-ART
review.

11. Change Log

[RFC EDITOR NOTE: Please remove this section when publishing]

Changes from draft-holmberg-dispatch-received-realm-11

o Editorial change based on IESG review.

Changes from draft-holmberg-dispatch-received-realm-10

o Changes based on IESG review.

o Changes based on SecDIR review.

o Changes based on IANA Service Operator review.

Changes from draft-holmberg-dispatch-received-realm-09

o Reference to RFC 2104 removed.

Changes from draft-holmberg-dispatch-received-realm-08

o Editorial fixed based on Gen-ART review.

o Editorial fixes based on comments from IANA Service Operator
review.

o - Quotes removed from sip_date value.

Changes from draft-holmberg-dispatch-received-realm-07

o Editorial changes.

Changes from draft-holmberg-dispatch-received-realm-06

o Changes based on AD review by Ben Campbell:

o - operator-id added to JSON Payload

Changes from draft-holmberg-dispatch-received-realm-05

o Editorial fixes.

Changes from draft-holmberg-dispatch-received-realm-04

o JSON serialization procedure added.

Changes from draft-holmberg-dispatch-received-realm-03

o ABNF correction.

Changes from draft-holmberg-dispatch-received-realm-02

o JWT replaced with JWS.

o Appendix F of RFC 7515 applied.

Changes from draft-holmberg-dispatch-received-realm-01

o Define received-realm parameter value as a JSON Web Token (JWT).

Changes from draft-holmberg-dispatch-received-realm-00

o New version due to expiration of previous version.

Changes from draft-holmberg-received-realm-04

o Changed IETF WG from sipcore do dispatch.

o HMAC value added to the parameter.

Changes from draft-holmberg-received-realm-03

o New version due to expiration.

Changes from draft-holmberg-received-realm-02

o New version due to expiration.

Changes from draft-holmberg-received-realm-01

o New version due to expiration.

Changes from draft-holmberg-received-realm-00

o New version due to expiration.

12. References

12.1.

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>.

[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <http://www.rfc-editor.org/info/rfc7638>.

12.2.

10.2. Informative References

[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
DOI 10.17487/RFC3968, December 2004,
<http://www.rfc-editor.org/info/rfc3968>.

[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>.

[TS.3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 14.1.0, September 2016. 2016,
<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.

Acknowledgements

Thanks to Adam Roach and Richard Barnes for providing comments and
feedback on the document. Francis Dupoint performed the Gen-ART
review.

Authors' Addresses

Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland

Email: christer.holmberg@ericsson.com

Yi Jiang
China Mobile
No.32 Xuanwumen West Street
Beijing Xicheng District 100053
P.R.
China

Email: jiangyi@chinamobile.com