Provider Alias Numbers for Session Initiation Protocol (SIP) User Agent Configuration
draft-lawrence-dispatch-sipforum-provider-alias-00

Abstract

This document defines procedures for how a SIP User Agent can translate an identifier provided by a user into the SIP DNS domain name of a service provider. The form of the user supplied identifier is constrained to values that can be entered using only a standard 12 key telephone keypad.

This document is derived from work begun in the SIP Forum Technical Working Group User Agent Configuration Task Group.

Status of this Memo

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

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 September 23, 2010.

Copyright Notice

Copyright (c) 2010 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 BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Numeric Domain Alias Entry
    3.1.  Provider Alias Number Resolution Example
4.  IANA Considerations
5.  Security Considerations
6.  Normative References
§  Authors' Addresses

1.  Introduction

Given the problem statement:

A user gets a new SIP User Agent (UA); it may be a hardware device or software. Some User Agents have a user interface that can accept a username, password, and domain name. Other devices, like Analog Telephony Adapters (ATAs), have no user interface other than that provided by an attached analog phone. How does a non-technical user minimally configure it so that when it is started, something useful happens?

The [draft‑sipforum‑user‑agent‑config] (Lawrence, S., Ed. and J. Elwell, “Session Initiation Protocol User Agent Configuration,” March 2010.) "Session Initiation Protocol (SIP) User Agent Configuration" specification provides a procedure for how a SIP User Agent locates, retrieves, and maintains current configuration information for a given SIP Service Provider. However, it assumes that either:

• the UA to be configured is connected to a network whose DHCP (or DHCPv6) service provides the DNS Name of the SIP domain for which configuration is desired,

or:

• the UA has a means by which the user can enter that SIP domain name.

Since some SIP UAs may have no more user interface than a standard 12 key telephone keypad (the digits 0 through 9, '*', and '#'), entry of DNS names (see [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.)), even for users comfortable with DNS names, is inconvenient at best. This leaves the problem of configuring a UA to obtain configuration for a SIP service provider whose domain name is not provisioned by the local network. This specification provides a means by which the UA can translate a value entered using only the standard telephone keypad into the DNS name of a SIP service provider; in the terminology of [draft‑sipforum‑user‑agent‑config] (Lawrence, S., Ed. and J. Elwell, “Session Initiation Protocol User Agent Configuration,” March 2010.), the "Configuration Service Domain Name".

2.  Terminology

The following terms are used in this document:

User Agent, UA

As defined in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). Note that this includes any implementation of a User Agent. A SIP phone is a User Agent, but the term also encompasses any other entity that uses SIP (for example: for a text chat, for sharing a whiteboard or for fax).

SIP Service Provider, Service Provider

An entity that provides services to User Agents using the SIP protocol. This specification requires that a Service Provider make configuration data and certain other information available in order to configure User Agents.

Configuration

The set of information that establishes operational parameters for a particular User Agent.

Configuration Service, CS

The source of Configuration for User Agents.

Configuration Service Domain

The DNS name for the service from which a Configuration is requested.

Provider Alias Number, PAN

A string consisting of decimal digits used to identify a domain from which configuration is to be requested.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Numeric Domain Alias Entry

A UA MAY have an interface by which a string consisting only of decimal digits, called a Provider Alias Number (PAN), is provided by the user. The PAN value is resolved to the Configuration Service Domain using the S-NAPTR (Simple NAPTR) DDDS application [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.).

The lookup key for the S-NAPTR request is the Provider Alias Number concatenated with a fixed root suffix (for the purposes of this initial draft, the value ".pan.sipforum.org." is used) to form a DNS domain name. The UA MUST make a DNS request for NAPTR records for that domain name. From the returned records (see next paragraph), the UA MUST select the record whose Service field value is "SFUA.PAN"; the Configuration Service Domain Name is the value found in the Replacement field of this record.

The DNS for the fixed root MUST be configured such that at most one NAPTR record is returned for any given Provider Alias Number, and MUST be configured to return the Flag field set to "a", an empty Regular Expression field, and the Substitution value set to the Configuration Service Domain Name.

3.1.  Provider Alias Number Resolution Example

Through some manual process, the UA has obtained the provider alias number "555". To obtain the Configuration Service Domain Name, the UA constructs a DNS NAPTR request by appending the domain suffix ".pan.sipforum.org." to form the query key "555.pan.sipforum.org.", which returns the DNS record:

                       NAPTR  10 10 "a" "SFUA.PAN" "" "example.net."

4.  IANA Considerations

This document registers the following S-NAPTR application service tag in the registry defined by [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)":

5.  Security Considerations

Because the mapping of the user-entered PAN value to Configuration Service Domain Name relies on a potentially unsecured DNS lookup, the UA SHOULD take steps to ensure that the correct provider has been found.

If possible, the resulting Configuration Service Domain Name SHOULD be confirmed by the human user.

Following the translation (specified in [draft‑sipforum‑user‑agent‑config] (Lawrence, S., Ed. and J. Elwell, “Session Initiation Protocol User Agent Configuration,” March 2010.)) of the Configuration Service Domain Name to the configuration request URL, the UA makes an https request for configuration data. Because this request is https, it is made over TLS. As the TLS server, the CS always provides a server certificate during the TLS handshake; if possible, the UA should validate that certificate and confirm that it contains the DNS name constructed from the PAN by concatenating the fixed root ("555.pan.sipforum.org" in the example in Section 3.1 (Provider Alias Number Resolution Example)). While it may not be possible to have the information needed to perform a full validation of the CS server certificate prior to the first configuration (for example, the UA may not have a current CA certificate for the CA that signs the CS server certificate), implementors are advised to provide for including that information in configuration data so that it can be used for subsequent reconfigurations; this narrows the window of vulnerability to the first configuration attempt.

6. Normative References

Authors' Addresses