Dispatch Working Group N. Weinronk Internet Draft Gamma Communications Intended status: Informational February 18, 2016 Expires: August 2016 Last Diverting Line Identity draft-weinronk-dispatch-last-diverting-line-id-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 18, 2016. Weinronk Expires August 18, 2016 [Page 1] Internet-Draft Last Diverting Line Identity February 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Abstract This document proposes an extension to the Session Initiation Protocol (SIP). In cases where applications/services (for example verification / billing) are provided by a network that is not the originating network the Network Asserted Identity is needed to provide these services. This extension provides the ability for a 'diversion service' to provide a Network Asserted Identity of the last diverting user to these applications/services. This extension defines a new general header, Last Diverting Line Identity which conveys the Network Asserted Identity of the diverting party to these applications/services. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Definitions ................................................. 3 4. Abbreviations ............................................... 3 5. Overview .................................................... 4 6. Formal Syntax ............................................... 5 7. Why not use existing headers................................. 6 8. Security Considerations...................................... 6 9. IANA Considerations ......................................... 7 9.1. Registration of SIP Last-Diverting-Line-Identity Header .. 7 9.2. Registration of "ldli" for SIP Privacy Headers...........7 10. References ................................................. 8 Weinronk Expires August 18, 2016 [Page 2] Internet-Draft Last Diverting Line Identity February 2016 10.1. Normative References................................... 8 11. Acknowledgments ............................................ 8 1. Introduction In cases where applications/services (for example verification / billing) are provided by a network that is not the originating network the Network Asserted Identity is needed to provide these services. This extension provides the ability for a 'diversion service' to provide a Network Asserted Identity of the last diverting user to these applications/services. This extension defines a new general header, Last Diverting Line Identity which conveys the Network Asserted Identity of the diverting party to these applications/services. In the legacy telephony network in the UK this information is provided by the Last Diverting Line Identity parameter. Note: This ISUP parameter is defined in the UK under the 'Nationally defined for National User' parameter code range of values. 2. Conventions used in this document 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 RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Definitions Diversion: The 'diversion service' could be defined as in [RFC7044] or as in [TS.24604]. NICC: The UK Interoperability Standards Organisation. 4. Abbreviations 3GPP - 3rd Generation Partnership Project Weinronk Expires August 18, 2016 [Page 3] Internet-Draft Last Diverting Line Identity February 2016 ETSI - European Telecommunication Standard Institute ISDN - Integrated Services Digital Network ISUP - ISDN User Part ITU - International Telecommunication Union SIP - Session Initiation Protocol TS - Technical Specification UA - User Agent UK - United Kingdom 5. Overview In cases where applications/services (for example verification / billing) are provided by a network that is not the originating network the Network Asserted Identity is needed to provide these services. This extension provides the ability for a 'diversion service' to provide a Network Asserted Identity of the last diverting user to these applications/services. This extension defines a new general header, Last Diverting Line Identity which conveys the Network Asserted Identity of the diverting party to these applications/services. It could be added by SIP UAs, SIP Redirect Servers or SIP Proxy Servers. In the legacy telephony network in the UK this information is provided by the Last Diverting Line Identity parameter. Note: This ISUP parameter is defined in the UK under the 'Nationally defined for National User' parameter code range of values. Example headers are: Last-Diverting-Line-Identity: Last-Diverting-Line-Identity: Weinronk Expires August 18, 2016 [Page 4] Internet-Draft Last Diverting Line Identity February 2016 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [RFC2234]. Definition of new Last Diverting Line Identity header field: The Last Diverting Line Identity header field is used among trusted SIP entities (typically intermediaries) to carry the verified identity of the diverting user. Last-Diverting-Line-Identity = "Last-Diverting-Line-Identity" HCOLON LDLI-value LDLI-value = name-addr A Last-Diverting-Line-Identity header field value MUST consist of exactly one name-addr. It MUST be a sip, sips or tel URI. 6.1 The "ldli" Privacy Type This specification adds a new priv-value to the Privacy header [RFC3323]. The presence of this privacy type in a Privacy header field indicates that the user would like the Last Diverting Line Identity to be kept private with respect to untrusted SIP entities. priv-value = "ldli" If the "ldli" priv-value is not present the LDLI-value presentation is allowed. If the "ldli" priv-value is present then the LDLI-value presentation is restricted. This document adds the following entry to Table 2 of [RFC3261]: Header field where proxy ACK BYE CAN INV OPT REG ----------- ----- ----- --- --- --- --- --- --- Last-Diverting-Line-Identity amdr - - - o - - Header field where proxy SUB NOT REF INF UPD PRA ----------- ----- ----- --- --- --- --- --- --- Last-Diverting-Line-Identity amdr - - - - - - Weinronk Expires August 18, 2016 [Page 5] Internet-Draft Last Diverting Line Identity February 2016 The Last-Diverting-Line-identity header carries the following information, with the mandatory parameters required when the header is included in a request: LDLI-value a mandatory parameter for capturing the Last Diverting Line Identity. 7. Why not use existing headers Use of the last History-Info header entry [RFC7044] was considered however this is mapped to/from the ISUP Redirecting Number and there are cases where the ISUP Redirecting Number is not the Network Asserted Identity of the last diverting user - for example the ETSI ISDN Partial Re-routing service as implemented in the UK. Note: In the UK the mapping would be to/from the new SIP header and the UK ISUP Last Diverting Line Identity parameter which provides the same functionality in UK ISUP leaving the ISUP Redirecting Number mapping to/from History-Info header as in the existing IETF / 3GPP / ITU / NICC specifications. 8. Security Considerations This document defines a header field for SIP. The use of the Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the overall confidentiality of the Last-Diverting-Line- Identity header fields is strongly RECOMMENDED. If TLS is NOT used, the intermediary MUST ensure that the messages are only sent within an environment that is secured by other means or that the messages don't leave the intermediary's domain. This results in Last- Diverting-Line-Identity's having at least the same level of security as other headers in SIP that are inserted by intermediaries. With TLS, Last-Diverting-Line-Identity header fields are no less, nor no more, secure than other SIP header fields, which generally have even more impact on the subsequent processing of SIP sessions than the Last-Diverting-Line-Identity header field. Note that while using the SIPS scheme (as per [RFC5630]) protects Last-Diverting-Line-Identity from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify Last-Diverting-Line-Identity. This specification does not attempt to prevent or detect attacks by malicious intermediaries. In terms of ensuring the privacy of LDLI-value, the same security considerations as those described in [RFC3323] apply. The Privacy Weinronk Expires August 18, 2016 [Page 6] Internet-Draft Last Diverting Line Identity February 2016 Service that's defined in [RFC3323] MUST also support the new Privacy header field priv-value of "ldli". 9. IANA Considerations 9.1. Registration of SIP Last-Diverting-Line-Identity Header This document defines a new SIP header field name: Last-Diverting-Line-Identity The following changes should be made to the header sub-registry under: http:///www.iana.org/assignments/sip-parameters The following row has been added to the header field section: Header Name Compact Form Reference ----------- ------------ --------- Last-Diverting-Line-Identity none [????] 9.2. Registration of "ldli" for SIP Privacy Headers This document defines a new priv-value for the SIP Privacy header: ldli The following changes should be made to http://www.iana.org/assignments/sip-priv-values The following has been added to the registration for the SIP Privacy header: Name Description Registrant Reference ---- ----------- ---------- --------- ldli Privacy requested for [????] [????] Last-Diverting-Line-Identity header Weinronk Expires August 18, 2016 [Page 7] Internet-Draft Last Diverting Line Identity February 2016 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009. [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044,February 2014. [TS.24604] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification" 11. Acknowledgments NICC SIP Task Group This document was prepared using 2-Word-v2.0.template.dot. Weinronk Expires August 18, 2016 [Page 8] Internet-Draft Last Diverting Line Identity February 2016 Authors' Address Nigel Weinronk Gamma Communications Phone: +443332403421 Email: nigel.weinronk@gamma.co.uk Contributors' Addresses Nick Ireland NICC Phone: +447889861066 Email: nick.ireland@niccstandards.org.uk Perry Wilks BT Phone: +442087262646 Email: perry.wilks@bt.com Weinronk Expires August 18, 2016 [Page 9]