Using the NETCONF Protocol over Transport Layer Security (TLS)
draft-ietf-netconf-rfc5539bis-05

Internet Engineering Task Force (IETF)                    H. Schulzrinne
Request for Comments: 8197                                           FCC
Category: Standards Track                                      July 2017
ISSN: 2070-1721

                 A SIP Response Code for Unwanted Calls

Abstract

   This document defines the 607 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for 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 this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8197.

Copyright Notice

   Copyright (c) 2017 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.  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.

Schulzrinne                  Standards Track                    [Page 1]
RFC 8197                     Status Unwanted                   July 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Normative Language  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Behavior of SIP Entities  . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  SIP Response Code . . . . . . . . . . . . . . . . . . . .   5
     5.2.  SIP Global Feature-Capability Indicator . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   In many countries, an increasing number of calls are unwanted
   [RFC5039]: they might be fraudulent or illegal telemarketing or maybe
   the receiving party does not want to be disturbed by, say, surveys or
   solicitation by charities.  Carriers and other service providers may
   want to help their subscribers avoid receiving such calls, using a
   variety of global or user-specific filtering algorithms.  One input
   into such algorithms is user feedback.  User feedback may be offered
   through smartphone apps, APIs or within the context of a SIP-
   initiated call.  This document addresses feedback within the SIP
   call.  Here, the called party either rejects the SIP [RFC3261]
   request as unwanted or terminates the session with a BYE request
   after answering the call.  INVITE and MESSAGE requests are most
   likely to trigger such a response.

   To allow the called party to express that the call was unwanted, this
   document defines the 607 (Unwanted) response code.  The user agent
   (UA) of the called party, based on input from the called party or
   some UA-internal logic, uses this to indicate that this call is
   unwanted and that future attempts are likely to be similarly
   rejected.  While factors such as identity spoofing and call
   forwarding may make authoritative identification of the calling party
   difficult or impossible, the network can use such a rejection --
   possibly combined with a pattern of rejections by other callees and/
   or other information -- as input to a heuristic algorithm for
   determining future call treatment.  The heuristic processing and
   possible treatment of persistently unwanted calls are outside the
   scope of this document.

Schulzrinne                  Standards Track                    [Page 2]
RFC 8197                     Status Unwanted                   July 2017

   When this document refers to "caller identity", it uses "identity" in
   the same sense as [SIP-IDENTITY], i.e., to mean either a canonical
   address-of-record (AOR) SIP URI employed to reach a user (such as
   'sip:alice@atlanta.example.com'), or a telephone number, which
   commonly appears in either a tel URI [RFC3966] or as the user portion
   of a SIP URI.

2.  Normative Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Motivation

   None of the existing 4xx, 5xx, or 6xx response codes signify that
   this SIP request is unwanted by the called party.  For example, 603
   (Decline) might be used if the called party is currently at dinner or
   in a meeting, but does not want to indicate any specific reason.  As
   described in Section 21.6.2 [RFC3261], a 603 response may include a
   Retry-After header field to indicate a better time to attempt the
   call.  Thus, the call is rejected due to the called party's
   (temporary) status.  As described in Section 4, the called party
   invokes the "unwanted call" user interface and 607 (Unwanted)
   response indicating that it is instead the caller's identity that is
   causing the call to be rejected.

4.  Behavior of SIP Entities

   The response code 607 MAY be used in a failure response for an
   INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP request to
   indicate that the offered communication is unwanted.  The response
   code MAY also be used as the value of the "cause" parameter of a SIP
   reason-value in a Reason header field [RFC3326], typically when the
   called party user agent issues a BYE request terminating an incoming
   call or a forking proxy issues a CANCEL request after receiving a 607
   response from one of the branches.  (Including a Reason header field
   with the 607 status code allows the called party user agent that
   receives a CANCEL request to make an informed choice whether and how
   to include such calls in their missed-call list or whether to show an
   appropriate indication to the user.)

gt;
      Description:            NETCONF over TLS (call home)
      Reference:              RFC XXXX
      Port Number:            YYYY

5.  Acknowledgements

   A significant amount of the text in Section 2.4 was lifted from
   [RFC4642].

   The authors like to acknowledge Martin Bjorklund, Olivier Coupelon,

Badra, et al.            Expires August 2, 2014                 [Page 8]
Internet-Draft              NETCONF over TLS                January 2014

   Mehmet Ersue, Miao Fuyou, David Harrington, Alfred Hoenes, Simon
   Josefsson, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen and
   the NETCONF mailing list members for their comments on this document.
   Charlie Kaufman, Pasi Eronen, and Tim Polk provided a the thorough
   review of previous versions of this document.  Stephen Hanna wrote
   the initial text for the applicability statement.

   Juergen Schoenwaelder and was partly funded by Flamingo, a Network of
   Excellence project (ICT-318488) supported by the European Commission
   under its Seventh Framework Programme.

6.  Contributor's Address

   Ibrahim Hajjeh
   Ineovation
   France

   EMail: ibrahim.hajjeh@ineovation.fr

7.  References

7.1.  Normative References

   [I-D.ietf-netmod-snmp-cfg]
              Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
              SNMP Configuration", draft-ietf-netmod-snmp-cfg-03 (work
              in progress), November 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
              for Transport Layer Security (TLS)", RFC 4279,
              December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509

Badra, et al.            Expires August 2, 2014                 [Page 9]
Internet-Draft              NETCONF over TLS                January 2014

              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, August 2011.

7.2.  Informative References

   [I-D.kwatsen-netconf-server]
              Watsen, K. and J. SchoeCnwaelder, "A YANG Data Model for
              NETCONF Server Configuration",
              draft-kwatsen-netconf-server-00 (work in progress),
              January 2014.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC4642]  Murchison, K., Vinocur, J., and C. Newman, "Using
              Transport Layer Security (TLS) with Network News Transfer
              Protocol (NNTP)", RFC 4642, October 2006.

   [RFC4742]  Wasserman, M. and T. Goddard, "Using the NETCONF
              Configuration Protocol over Secure SHell (SSH)", RFC 4742,
              December 2006.

   [RFC5539]  Badra, M., "NETCONF over Transport Layer Security (TLS)",
              RFC 5539, May 2009.

Appendix A.  Change Log (to be removed by RFC Editor before publication)

A.1.  draft-ietf-netconf-rfc5539bis-05

   o  Removed the YANG configuration data model since it became a
      separate document.

   o  Added reference to RFC 3234 plus editorial updates.

Badra, et al.            Expires August 2, 2014                [Page 10]
Internet-Draft              NETCONF over TLS                January 2014

A.2.  draft-ietf-netconf-rfc5539bis-04

   o  Added the applicability statement proposed by Stephen Hanna.

   o  Added call-home configuration objects and a tls-call-home feature.

   o  Rewrote the text such that the role swap happens right after the
      TCP connection has been established.

A.3.  draft-ietf-netconf-rfc5539bis-03

   o  Added support for call home (allocation of a new port number,
      rewrote text to allow a NETCONF client to be a TLS server and a
      NETCONF server to be a TLS client).

   o  Merged sections 2 and 3 into a new section 2 and restructured the
      text.

   o  Extended the IANA considerations section.

   o  Using the cert-to-name mapping grouping from the SNMP
      configuration data model and updated the examples.

   o  Creating an extensible set of YANG (sub)modules for NETCONF
      following the (sub)module structure of the SNMP configuration
      model.

A.4.  draft-ietf-netconf-rfc5539bis-02

   o  Addressed remaining issues identified at IETF 85

      *  Harmonized the cert-maps container of the YANG module in this
         draft with the tlstm container in the ietf-snmp-tls sub-module
         specified in draft-ietf-netmod-snmp-cfg.  Replaced the children
         of the cert-maps container with the children copied from the
         tlstm container of the ietf-snmp-tls sub-module.

      *  Added an overview of data model in the ietf-netconf-tls YANG
         module.

      *  Added example configurations.

   o  Addessed issues posted on NETCONF WG E-mail list.

   o  Deleted the superfluous tls container that was directly below the
      netconf-config container.

Badra, et al.            Expires August 2, 2014                [Page 11]
Internet-Draft              NETCONF over TLS                January 2014

   o  Added a statement to the text indicating that support for mapping
      X.509 certificates to NETCONF usernames is optional.  This is
      analogous to existing text indicating that support for mapping
      pre-shared keys to NETCONF usernames is optional.  Resource-
      constrained systems now can omit support for mapping X.509
      certificates to NETCONF usernames and still comply with this
      specification.

   o  Clarified the document structure by promoting the sections of the
      document related to the data model.

   o  Updated author's addresses.

A.5.  draft-ietf-netconf-rfc5539bis-00

   o  Remove the reference to BEEP.

   o  Rename host-part to domain-part in the description of RFC822.

Authors' Addresses

   Mohamad Badra
   LIMOS Laboratory

   Email: mbadra@gmail.com

   Alan Luchuk
   SNMP Research, Inc.
   3001 Kimberlin Heights Road
   Knoxville, TN  37920
   US

   Phone: +1 865 573 1434
   Email: luchuk@snmp.com
   URI:   http://www.snmp.com/

Badra, et al.            Expires August 2, 2014                [Page 12]
Internet-Draft              NETCONF over TLS                January 2014

   Juergen Schoenwaelder
   Jacobs University Bremen
   Campus Ring 1
   28759 Bremen
   Germany

   Phone: +49 421 200 3587
   Email: j.schoenwaelder@jacobs-university.de
   URI:   http://www.jacobs-university.de/

Badra, et al.            Expires August 2, 2014                [Page 13]