SIP Working Group D. Willis, Ed.
Internet-Draft Unaffiliated Individual
Intended status: Standards Track A. Allen
Expires: December 14, 2007 Research in Motion (RIM)
June 12, 2007
Requesting Answering Modes for the Session Initiation Protocol (SIP)
draft-ietf-sip-answermode-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 14, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines extends SIP with two header fields and
associated option tags that can be used in INVITE requests to convey
the requester's preference for user-interface handling related to
answering of that request. The first header, "Answer-Mode",
expresses a preference as to whether the target node's user interface
waits for user input before accepting the request or instead accepts
the request without waiting on user input. The second header, "Priv-
Willis & Allen Expires December 14, 2007 [Page 1]
Internet-Draft SIP Answering Modes June 2007
Answer-Mode" is similar to the first, except that it requests
administrative-level access and has consequent additional
authentication and authorization requirements. These behaviors have
applicability to applications such as Push-to-Talk and to diagnostics
like loop-back. Usage of each header field in a response to indicate
how the request was handled is also defined.
Requirements Language
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].
Willis & Allen Expires December 14, 2007 [Page 2]
Internet-Draft SIP Answering Modes June 2007
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Syntax of Header Fields and Option Tags . . . . . . . . . . . 7
3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields . 7
4. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Requests . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Procedures at User Agent Clients (UAC) . . . . . . . . . . 9
4.1.1. All Requests . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. REGISTER Transactions . . . . . . . . . . . . . . . . 9
4.1.3. INVITE Transactions . . . . . . . . . . . . . . . . . 9
4.2. Procedures at Intermediate Proxies . . . . . . . . . . . . 11
4.2.1. General Proxy Behavior . . . . . . . . . . . . . . . . 11
4.2.2. Issues with Automatic Answering and Forking . . . . . 11
4.3. Procedures at User Agent Servers (UAS) . . . . . . . . . . 12
4.3.1. INVITE Transactions . . . . . . . . . . . . . . . . . 12
4.3.2. Special Considerations for Priv-Answer-Mode . . . . . 13
5. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Responses . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedures at the UAS . . . . . . . . . . . . . . . . . . 15
5.2. Procedures at the UAC . . . . . . . . . . . . . . . . . . 15
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 15
6.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 16
6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . . 16
6.3. 200 (OK) Response . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Attack Sensitivity Depends on Media Characteristics . . . 17
7.2. Application Design Affects Attack Opportunity . . . . . . 19
7.3. Applying the Analysis . . . . . . . . . . . . . . . . . . 19
7.4. Minimal Policy Requirement . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. Registration of Header Fields . . . . . . . . . . . . . . 21
8.2. Registration of Header Field Parameters . . . . . . . . . 22
8.3. Registration of SIP Option Tags . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Willis & Allen Expires December 14, 2007 [Page 3]
Internet-Draft SIP Answering Modes June 2007
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Willis & Allen Expires December 14, 2007 [Page 4]
Internet-Draft SIP Answering Modes June 2007
1. Background
There has been discussion of how to deal with "auto-answer" and
related issues in the SIP community for several years. Discussion in
the SIPPING working group, augmented by input from other
organizations such as the Open Mobile Alliance, resulted in a
consensus observed in the SIPPING meeting at IETF 62 to extend SIP,
which is defined in [RFC3261]. Further discussion of the topic on
the SIP mailing list after IETF 62 led to a consensus to pursue this
work in the SIP working group as a standards-track effort.
Two different use cases converged to create the consensus for the
development of this specification. Other use cases presumably exist,
but two is enough to establish the level of reusability required to
justify a standards-track extension as opposed to a "P-header" under
[RFC3427].
The first key use case was the requirement for diagnostic loopback
calls. In this sort of scenario, a testing service sends an INVITE
to a node being tested. The tested node accepts and a dialog is
established. But rather than establishing a two-way media flow, the
tested node loops back or "echoes" media received from the testing
service back toward the testing service. The testing service can
then analyze the media flow for quality and timing characteristics.
SDP usage for this sort of flow is described in
[I-D.ietf-mmusic-media-loopback]. In this sort of application, it
might not be necessary that the human using the node under test
interact with the node in any way for the test to be satisfactorily
executed. In some cases, it might be appropriate to alert the user
to the ongoing test, and in other cases it might not be.
The second use case is that of "Push to Talk" applications being
specified by the Open Mobile Alliance. In this sort of environment,
SIP is used to establish `a dialog supporting asynchronous delivery
of unidirectional media flow, giving a user experience like that of a
traditional two-way radio. It is conventional for the INVITES used
to be automatically accepted by the called UA (User Agent), and the
media is commonly played out on a loudspeaker.
Another representative use case was introduced during discussion of
this topic on the mailing list of the SIP working group. Traditional
office PBX systems often include intercom functionality. A typical
use for the intercom function is to allow a receptionist to activate
a loudspeaker on a desk telephone in order to announce a visitor.
Not every caller can access the loudspeaker, only the receptionist or
operator, and it is not expected that these callers will always want
"intercom" functionality -- they might instead want to make an
ordinary call.
Willis & Allen Expires December 14, 2007 [Page 5]
Internet-Draft SIP Answering Modes June 2007
The above list of use cases is not exhaustive. There are presumably
many more use cases for the extensions defined in this specification.
These sorts of mechanisms are not required to provide the
functionality of an "answering machine" or "voice mail recorder".
Such a device knows that it is expected to answer and does not
require a SIP extension to support its behavior.
Much of the discussion of this topic in working group meetings and on
the mailing list dealt with differentiating "answering mode" from
"alerting mode". Some early work did not make this distinction. We
therefore proceed with the following definitions:
o Answering Mode includes behaviors in a SIP UA relating to
acceptance or rejection of a request that are contingent on
interaction between the UA and the user of that UA after the UA
has received the request. We are principally concerned with the
user interaction involved in accepting the request and initiating
an active session. An example of this might be pressing the "yes"
button on a mobile phone.
o Alerting Mode includes behaviors in a SIP UA relating to to
informing the user of the UA that a request to initiate a session
has been received. An example of this might be activating the
ring tone of a mobile phone.
This document deals only with "Answering Mode". Issues relating to
"Alerting Mode" are outside its scope.
This document defines two SIP extension header fields, "AnswerMode"
and "PrivAnswerMode". These two extensions take the same parameters
and operate in the same general way.
The distinction between Answer-Mode and Priv-Answer-Mode relates to
the level of authorization being claimed by the UAC and verified and
policed by by the UAS. Requests are usually made using Answer-Mode.
Requests made using Priv-Answer-Mode request "privileged" treatment
from the UAS. This mechanism is discussed in greater detail below
under the heading "Special Considerations for Priv-Answer-Mode".
Priv-Answer-Mode is not an assertion of privilege. Instead, it is a
request for privileged treatment. This is similar to the UNIX model
where a user might run a command normally, or use "sudo" to request
administrative privilege for the command. Including the "Priv-" part
is equivalent to prefixing a UNIX command with "sudo".
This distinction is discussed in greater detail in this document in
the section "Special Considerations for PrivAnswerMode."
Willis & Allen Expires December 14, 2007 [Page 6]
Internet-Draft SIP Answering Modes June 2007
2. Syntax of Header Fields and Option Tags
The following syntax uses ABNF as defined in [RFC4234].
The syntax for the header fields defined in this document is:
Answer-Mode = "Answer-Mode" HCOLON answer-mode-value *(SEMI
answer-mode-param)
Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-value
*(SEMI answer-mode-param)
answer-mode-value = "Manual" / "Auto" / token
answer-mode-param= "require" / generic-param
The SIP option tag indicating support for this extension is
"answermode".
For implementors: SIP header field names and values are always
compared in a case-insensitive manner. The pretty capitalization
is just for readability.
This syntax includes extension hooks, "token" for answer-modes
values, and "generic-param" for optional parameters, that could be
defined in future specifications extending this one. This
specification defines only the behavior for the values given
explicitly above. In order to provide forward compatibility,
implementations MUST ignore unknown values.
3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields
This document defines usage of the Answer-Mode and Priv-Answer-Mode
header fields in initial (dialog-forming) SIP INVITE requests and in
200 (OK) responses to those requests. This document specifically
does not define usage in any other sort of request or response,
including but not limited to ACK, CANCEL, or any mid-dialog usage.
This limitation stems from the intended usage of this extension,
which is to affect the way that users interact with communications
devices when requesting new communications sessions and when
responding to such requests. This sort of interaction generally
occurs only during the formation of a dialog and its initial usage,
and not during subsequent operations such as re-INVITE.
Willis & Allen Expires December 14, 2007 [Page 7]
Internet-Draft SIP Answering Modes June 2007
4. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in
Requests
The Answer-Mode or Priv-Answer-Mode header field is used by a UAC in
an INVITE request to invoke specific handling by the responding UAS
related to "automatic answering" functionality for any dialog
resulting from that INVITE request. If no Answer-Mode or Priv-
Answer-Mode header field is included in the request, answering
behavior is at the discretion of the UAS, as it would be in the
absence of this specification. The desired handling is indicated by
the value of the Answer-Mode or Priv-Answer-Mode header field, as
follows:
Manual: The UAS is asked to not accept the request until the user of
the UAS has interacted with the user interface (UI) of the UAS in
such a way as to indicate that the user desires the UAS to accept
the request.
Auto: The UAS is asked to accept the request automatically, without
waiting for the user of the UAS to interact with the UI of the UAS
in such a way as to indicate that the user desires the UAS to
accept the request.
Each value of the Answer-Mode or Priv-Answer-Mode header field can
include an optional parameter, "require". If present, this parameter
indicates that the UAS would prefer that the UAC reject the request
if the UAC is unwilling (perhaps due to policy) to answer in the mode
requested, rather than answering in another mode. For example, this
parameter could be used to make sure that a test "loopback" call
doesn't disturb a user who has configured her phone to manually
answer even if the caller requests an automatic answer.
The UAS is responsible for deciding how to honor this preference. In
general, the UAS makes an authorization decision based on the
authenticated identity presented in the request using authentication
mechanisms such as SIP Digest Authentication [RFC3261], the SIP
Identity mechanism [RFC4474], or (within the restricted networks for
which it is suitable) the SIP mechanism for asserted identity within
trusted networks [RFC3325] and using authorization information or
policy available to the UAS. This decision making MUST consider the
risk model of the media session corresponding to the request, and the
UAS MUST NOT answer without user input in cases where the privacy or
security of the user would be compromised as a result. Specific
discussion of media sessions and appropriate policy is discussed
under "Security Considerations", below.
Willis & Allen Expires December 14, 2007 [Page 8]
Internet-Draft SIP Answering Modes June 2007
4.1. Procedures at User Agent Clients (UAC)
4.1.1. All Requests
A UAC supporting the Answer-Mode and Priv-Answer-Mode header fields
indicates its support by including an option tag of "answermode" in
the Supported header field of all requests it sends.
4.1.2. REGISTER Transactions
To indicate that it supports the answer-mode negotiation feature, a
UA includes an extensions parameter with a value that includes
"answermode". Example:
;extensions="answermode,100rel,gruu"
in the Contact: header field of its REGISTER requests. This usage of
feature tags is described in [RFC3840].
4.1.3. INVITE Transactions
A UAC supporting this specification includes an Answer-Mode or Priv-
Answer-Mode header field in an INVITE where it wishes to influence
the answering mode of the responding UAS.
Note: this is meaningful only in initial or dialog-forming INVITE
requests.
To request that the UAS answer only after having interacted with its
user and receiving an affirmative instruction from that user, the UAC
includes an Answer-Mode or Priv-Answer-Mode header field having a
value of "Manual". Example:
Answer-Mode: Manual
To request that the UAS answer manually, and ask that it reject the
INVITE request if unable or unwilling to answer manually, the UAC
includes an Answer-Mode or Priv-Answer-Mode header field having a
value of "Manual" and a parameter of "require". Example:
Answer-Mode: Manual;require
To request that the UAS answer automatically without waiting for
input from the user, the UAC includes an Answer-Mode or Priv-Answer-
Mode header field having a value of "Auto". Example:
Answer-Mode: Auto
Willis & Allen Expires December 14, 2007 [Page 9]
Internet-Draft SIP Answering Modes June 2007
To request that the UAS answer automatically, and ask that it reject
the INVITE request if unable or unwilling to answer automatically,
the UAC includes an Answer-Mode or Priv-Answer-Mode header field
having a value of "Auto" and a parameter of "require". Example:
Answer-Mode: Auto;require
To require that the UAS either support this extension or reject the
request, the UAC includes a Require: header field having the value
"answermode". This does not actually force the UAS to automatically
answer, it just requires that the UAS either understand this
extension or reject the request. We do not have a SIP negotiation
technique to force specific behavior. Rather, the desired behavior
is indicated in the SIP extension itself. Example:
Require: answermode
To request that retargeting proxies in the path preferentially select
targets that have indicated support for this extension in their
registration, a UAC includes an Accept-Contact header field with an
extensions parameter having a value of "answermode". This usage of
Accept-Contact is described in [RFC3841]. This would normally be
used in conjunction with the "Require: answermode" header field as
described above. Example:
Require: answermode
Accept-Contact: *;extensions="answermode";methods="INVITE"
To request that retargeting proxies in the path do not select targets
that have indicated non-support for this extension in their
registration, a UAC includes an Accept-Contact header field with an
extensions parameter having a value of "answermode" and an option
field of "require". This usage of Accept-Contact is described in
[RFC3841]. This would normally be used in conjunction with the
"Require: answermode" header field as described above. Example:
Require: answermode
Accept-Contact: *;extensions="answermode";
methods="INVITE";require
To request that retargeting proxies in the path exclusively select
targets that have indicated support for this extension in their
registration, a UAC includes an Accept-Contact header field
extensions parameter having a value of "answermode"" and options of
"require" and "explicit". This usage of Accept-Contact is described
in [RFC3841]. This would normally be used in conjunction with the
Willis & Allen Expires December 14, 2007 [Page 10]
Internet-Draft SIP Answering Modes June 2007
"Require: answermode" header field as described above.
Require: answermode
Accept-Contact: *;extensions="answermode";
methods="INVITE";require;explicit
4.2. Procedures at Intermediate Proxies
4.2.1. General Proxy Behavior
The general procedure at all intermediate proxies including the UAC's
serving proxy or proxies and the UAS's serving proxy or proxies is to
ignore the Answer-Mode header field. However, the serving proxies
(proxies responsible for resolving an address-of-record into a
registered contact) MAY exercise control over the requested answer
mode, either inserting or deleting an Answer-Mode or Priv-Answer-Mode
header field or altering the value of an existing header field in
accord with local policy. This could result in behavior that is
inconsistent with user expectations (such as having a call that was
intended to be a diagnostic loopback answered by a human) and
consequently proxies MUST NOT alter Answer-Mode or Priv-Answer-Mode
header fields unless explicitly authorized to do so by an external
agreement between the proxy operator and the user of the UA that the
proxy is serving. These serving proxies MAY also reject a request
according to local policy, and SHOULD use the rejection codes as
specified below for the UAS if they do so.
4.2.2. Issues with Automatic Answering and Forking
One of the well-known issues with forking is the problem of multiple
acceptance. If an INVITE request is forked to several UASes, and
more than one of those replies with a 200 (OK) response, the
conventional approach is to continue the dialog with the first
respondent, and tear down the dialog (using BYE requests) with all
other respondents.
While this problem exists without an auto-answer negotiation
capability, it is apparent that widespread adoption of UAs that
engage in auto-answer behavior will exacerbate the multiple
acceptance problem. Consequently, systems designers need to take
this aspect into consideration. In general, auto-answer is NOT
RECOMMENDED in environments that include parallel forking.
As an alternative, it might be reasonable to use a variation on
manual-answer combined with no alerting and early media. In this
approach, the initial message or talk-burst is transmitted as early
media to all recipients, where it is displayed or played out. Any
Willis & Allen Expires December 14, 2007 [Page 11]
Internet-Draft SIP Answering Modes June 2007
response utterance (pushing the transmit key and talking) from the
user of a UAS following this would serve as an "acceptance",
resulting in a 200 (OK) response being transmitted by their UAS.
Consequently, the race-condition for acceptance would be limited to
the subset of UAs actually responding under user control, rather than
the full set of UAs to which the request was forked.
Another alternative would be to use dynamic conferencing instead of
forking. In this approach, instead of forking the request, a
conference would be initiated and all UAs invited into that
conference. The mixer attached to the conference would then mediate
traffic flows appropriately.
4.3. Procedures at User Agent Servers (UAS)
4.3.1. INVITE Transactions
For a request having an Answer-Mode value of "Manual" and not having
an Answer-Mode parameter of "require", the UAS SHOULD defer accepting
the request until the user of the UAS has confirmed willingness to
accept the request. This behavior MAY be altered as needed for
unattended UASes or other local characteristics or policy. For
example, an auto-attendant or PSTN gateway system that always answers
automatically would go ahead and answer, despite the presence of the
"Manual" Answer-Mode header field value.
For a request having an Answer-Mode value of "Manual" and an Answer-
Mode parameter of "require", the UAS MUST defer accepting the request
until the user of the UAS has confirmed willingness to accept the
request. If the UAS is not capable of answering the request in this
"Manual" mode or is unwilling to do so, it MUST reject the request
and SHOULD do so with a "403 (Forbidden)" response and MAY include a
reason phrase of "manual answer forbidden".
For a request having an Answer-Mode value of "Auto", the UAS SHOULD,
if the calling party is authenticated and authorized for automatic
answering, accept the request without further user input. The UAS
MAY, according to local policy or user preferences, treat this
request as it would treat a request having an Answer-Mode with a
value of "Manual" or having no Answer-Mode header field. If the
calling party is not authenticated and authorized for automatic
answer, the UAS MAY either handle the request as per "manual", or
reject the request. If the UAS rejects the request, it SHOULD do so
with a "403 (Forbidden)" response, and MAY include a reason phrase of
"automatic answer forbidden".
For a request having an Answer-Mode value of "Auto" and an Answer-
Mode parameter of "require", the UAS SHOULD, if the calling party is
Willis & Allen Expires December 14, 2007 [Page 12]
Internet-Draft SIP Answering Modes June 2007
authenticated and authorized for automatic answering, accept the
request. The UAS MUST NOT allow "manual" answer of this request, but
MAY reject it. If, for whatever reason, the UAS chooses not to
accept the request automatically, the UAS MUST reject the request and
SHOULD do so with a "403 (Forbidden)" response, and MAY include a
reason phrase of "automatic answer forbidden"
4.3.2. Special Considerations for Priv-Answer-Mode
The Answer-Mode and Priv-Answer-Mode header fields have equivalent
functions, except that Priv-Answer-Mode requests a higher level of
privilege in granting the answering mode specified by the request.
The model for this is that an "administrative level of privilege" is
requested -- where "Answer-Mode" says "Please answer in the following
mode, if your user preferences allow it", the Priv-Answer-Mode says
"I command you to answer in the following mode, even if your user
preferences would ordinarily disallow it". The UAS MUST NOT grant
this override capability to an unauthenticated UAC, and SHOULD apply
a stricter authorization policy to a request with Priv-Answer-Mode
header fields than it does to requests with Answer-Mode header
fields. The default policy SHOULD be to refuse requests containing
"Priv-Answer-Mode" header fields.
The use case envisioned for Priv-Answer-Mode relates to handling
urgent requests from authorized callers. For example, assume Larry
is a limousine driver working with a fleet dispatcher. Larry likes
to provide a quiet environment for his car, so his communicator is
configured for manual answer mode for push-to-talk calls. Each time
he gets a push-to-talk call, Larry's communicator chimes softly to
alert him to the call. If the circumstances permit it, Larry presses
the communicator in order to accept the call, the communicator sends
a 200 (OK) response, and the calling party's talk burst is played out
through the communicator's loudspeaker. This treatment is delivered
to incoming requests that have an Answer-Mode header field having
values of "Manual" or "Auto" (or no Answer-Mode header field at all)
no matter who the caller is.
Larry's fleet dispatch operator is familiar with this policy, and
needs to inform Larry about a critical matter. The dispatch operator
tries several times to call Larry (including Answer-Mode: Auto in the
requests), but the calls aren't accepted because Larry has fallen
asleep, and therefore isn't pressing his communicator to accept the
call.
The operator then presses his "urgent" button and calls Larry again.
This time, the INVITE request carries a "Priv-Answer-Mode: Auto"
header field. Larry's communicator checks the identity of the caller
(using a SIP Identity assertion or functionally equivalent
Willis & Allen Expires December 14, 2007 [Page 13]
Internet-Draft SIP Answering Modes June 2007
mechanism), and matches the operator's identity against the list of
users allowed to do Priv-Answer-Mode. Since the operator is listed,
the communicator immediately returns a 200 (OK) response accepting
the call. The operator speaks, and the resulting talk-burst is
summarily played out the loudspeaker on Larry's communicator, waking
him up.
The effect of requesting Priv-Answer-Mode is different than the
effect of simply granting higher privilege to an Answer-Mode request
based on the requester's identity and corresponding authorization
level. This distinction is what allows the fleet operator to make
polite (Answer-Mode: Auto) requests to Larry under normal conditions,
and receive different handling (Priv-Answer-Mode: Auto) for a request
having greater urgency.
In normal operations, only one of "Answer-Mode" and "Priv-Answer-
Mode" would be used in an INVITE request. If both are present, the
UAS will first test the authorization of the requester for Priv-
Answer-Mode, and if authorized, process the request as if only Priv-
Answer-Mode had been included. If the requester is not authorized
for Priv-Answer-Mode, then the UAS will process the request as if
only "Answer-Mode" had been included.
5. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in
Responses
The Answer-Mode header field or Priv-Answer-Mode can be inserted by a
UAS into a response in order to indicate how it handled the
associated request with respect to automatic answering functionality.
The UAC might use this information to inform the user or otherwise
adapt the behavior of the user interface. The handling is indicated
by the value of the header field, as follows:
Manual: The UAS responded after the user of the UAS interacted with
the user interface (UI) of the UAS in such a way as to indicate
that the user desires the UAS to accept the request.
Auto: The UAS responded automatically, without waiting for the user
of the UAS to interact with the UI of the UAS in such a way as to
indicate that the user desires the UAS to accept the request.
The Answer-Mode and Priv-Answer-Mode header fields, when used in
responses, are only valid in a 200 (OK) response to an INVITE
request.
Willis & Allen Expires December 14, 2007 [Page 14]
Internet-Draft SIP Answering Modes June 2007
5.1. Procedures at the UAS
A UAS supporting this specification inserts an Answer-Mode or Priv-
Answer-Mode header field into the 200 (OK) response to an INVITE
request when it wishes to inform the UAC as to whether the request
was answered manually or automatically. It is reasonable for a UAS
to assume that if the UAC included an Answer-Mode header field in the
request that it would probably like to see an Answer-Mode header
field in the response. The full rationale for including or not
including this header field in a response is outside of the scope of
this specification, and is sensitive to the privacy concerns of the
user of the UAS. For example, informing the calling party that a
call was answered manually might reveal the presence of an "actual
human" at the responding UAS. While in the general case the ensuing
conversation would also reveal this same information, there might be
cases where this information might need to be protected.
Consequently, UAS supporting this specification SHOULD include
appropriately configurable policy mechanisms for making this
determination, and the default configuration SHOULD be to not include
this header field in responses.
5.2. Procedures at the UAC
A UAC MAY use the value of the Answer-Mode or Priv-Answer-Mode header
field, if present, to adapt the user interface and/or inform the user
about the handling of the request. For example, the user of a push-
to-talk system might speak differently if she knows that the called
party answered "in person" vs. having the call blare out of an
unattended speaker phone.
6. Examples of Usage
The following examples show Bob registering a contact that supports
the negotiation of answering mode. Alice then calls Bob with an
INVITE request, asking for automatic answering and explicitly asking
that the request not be routed to contacts that have not indicated
support for this extension. Further, Alice requires that the request
be rejected if Bob's UA does not support negotiation of answering
mode. Bob replies with a 200 (OK) response indicating that the call
was answered automatically.
The Content-Length header field shown in the examples contains a
placeholder "..." instead of a valid Content-Length. Furthermore,
the SDP bodies that would be expected in the INVITE requests and
200 (OK) responses are not shown.
Willis & Allen Expires December 14, 2007 [Page 15]
Internet-Draft SIP Answering Modes June 2007
6.1. REGISTER Request
In the following example, Bob's UA is registering and indicating that
it supports the answermode extension.
REGISTER sip:example.com SIP/2.0
From: Bob<sip:bob@example.com>
To: Bob <sip:bob@example.com>
Contact: sip:cell-phone@example.com;
extensions="answermode";
methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
6.2. INVITE Request
In this example, Alice is calling Bob and asking Bob's UA to answer
automatically. However, Alice is willing for Bob to answer manually
if Bob's policy is to prefer manual answer.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>
Call-ID:3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Require: answermode
Accept-contact:*;require;explicit;extensions="answermode"
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
6.3. 200 (OK) Response
Here, Bob has accepted the call and his UA has answered
automatically, which it indicates in the 200 (OK) response.
SIP/2.0 200 OK
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
From: Alice <sip:alice@example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>;tag=8321234356
Call-ID: 3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Answer-Mode: Auto
Willis & Allen Expires December 14, 2007 [Page 16]
Internet-Draft SIP Answering Modes June 2007
Content-Type: application/sdp
Content-Length: ...
7. Security Considerations
This specification adds the ability for a UAC to request potentially
risky user interface behavior relating to the acceptance of an INVITE
request by the UAS receiving the request. Specifically, the UAC can
request that the UAS accept the request without input to the UAS by
the user of the UAS (Answer-Mode: Auto).
There are several attacks possible here, with the most obvious being
the ability to turn a phone into a remote listening device without
its user being aware of it. Additional potential attacks include
reverse charge fraud, unsolicited "push to talk" communications (spam
over push-to-talk or SPPTT), playout of obnoxious noises (the
"whoopee cushion" attack), battery-rundown denial-of-service, "forced
busy" denial of service, and phishing via session insertion (where an
ongoing session is replaced by another without the victim's
awareness).
The existing body of SIP work provides strong capabilities for
authentication of requests, prevention of man-in-the-middle attacks,
protecting the privacy and integrity of media flows, and so on. The
behaviors added by the extensions in this document raise additional
possibilities for attacks against media flows not completely
addressed by existing SIP work, and therefore require analysis in
this document.
Media attacks can be loosely categorized as:
Insertion: Media is inserted into and played out by the victim UA
without consent of the UA's user.
Interception: The victim UA's media acquisition facility (such as a
microphone or camera) is activated, producing a media stream,
without the consent of the UA's user.
7.1. Attack Sensitivity Depends on Media Characteristics
The danger of abuse varies greatly depending on the media
characteristics of the session being established. Since the
expressive range of media sessions that can be established by SIP is
unbounded, we might find it more effective to model loose categories
of media modality rather than explicitly describing every possible
scenario. Security analysis can then be applied per modality.
Willis & Allen Expires December 14, 2007 [Page 17]
Internet-Draft SIP Answering Modes June 2007
The media modalities of interest appear to be:
UAC-sourced (Inbound) Unidirectional Media Insertion: Sensitive
media flows from the UAC and is rendered by the UAS, annoying the
user of the UAS or disrupting the function of the UAS. We refer
to this as the "whoopee-cushion" attack because of its utility in
replicating the rude-noise making joke seat cushion. The danger
of this attack is quite literally amplified by a loudspeaker
apparatus attached to the victim UAS. Media that has minimal
secondary implication (such as sending a move in a chess game to a
computer that isn't running a chess game) is related, but of far
less significance.
UAS-sourced (Outbound) Unidirectional Media Interception: Sensitive
media flows from the UAS and is rendered by the UAC, violating the
privacy of the user of the UAS. We refer to this as the "bug-my-
phone" attack because that would appear to be primary attack
motivator.
Bidirectional Media Insertion or Interception: Bidirectional media
is the common case when SIP is used in a voice-over-IP scenario or
"traditional phone call". Once a media flow is established, both
ends send and receive media without further engagement. The media
information is presumed to be sensitive -- that is, if intercepted
it damages the victim's privacy, and if inserted, it annoys or
interferes with the recipient. Attacks of this sort might produce
both of the "whoopee-cushion" or the "bug-my-phone" scenarios,
potentially even simultaneously.
It seems reasonable to consider the "bug-my-phone" attack as being in
a different class (potentially far more severe) than the "whoopee-
cushion" attack. This distinction suggests that security policy
could be established in different and presumably less restrictive
fashion for inbound media flows than for outbound media flows. The
set of callers from which a user would be willing to automatically
accept inbound media is reasonably much broader than the set of
callers to which a user would be willing to automatically grant
outbound media access.
For example: Assume a UA is designed such that it can be used to
receive push-to-talk calls to a loudspeaker, and it can be used as a
"baby monitor" (has an open mic and streams received audio to
listeners). The policy for activating the push-to-talk loudspeaker
would probably need to be reasonably broad (perhaps "all the user's
buddies"), but the policy for the baby monitor would need to be very
narrow (perhaps only "the baby's mother) or even completely closed.
Willis & Allen Expires December 14, 2007 [Page 18]
Internet-Draft SIP Answering Modes June 2007
7.2. Application Design Affects Attack Opportunity
In the most common use cases, the security aspects are somewhat
mitigated by design aspects of the application. For example, in
traditional telephony, the called party is alerted to the request
(the phone rings), no media session is established without the
acceptance of the called party (picking up the phone), and the media
path is most commonly delivered to a single-user handset.
Consequently, this application (although bidirectional) is relatively
secure against both media insertion and media interception attacks of
the sort enabled by the extensions in this document. The use of
policy-free automatic-answering devices (like answering machines) and
amplifiers (speakerphones and call-screening devices) weakens this
defense.
In push-to-talk applications, media can be sent from UAC to UAS
without user oversight, but no media is sent from the called UAS
without user input (the "push" of "push-to-talk"). Consequently,
there is no "bug-my-phone" attack opportunity. Further, screening of
the UAC by eliminating UAC identities not on some sort of "white
list" (often, a buddy list) reduces the threat of "whoopee cushion"
attacks (except from one's buddies, of course).
Similar approaches apply to most applications. Insertion can be
controlled (but not eliminated) by combining identity mechanisms with
simple authorization policy, and interception can be effectively
eliminated by combining strong identity mechanisms with aggressive
authorization policy and/or user interaction.
7.3. Applying the Analysis
The extensions described in this document provide mechanisms by which
a UAC can request that a UAS not deploy two of the five defensive
mechanisms -- user alerting and user acceptance. In order for this
to not produce undue risk of insertion attacks or any increased risk
of interception attacks, we are therefore forced to rely on the
remaining defensive mechanisms. This document defines a minimum
threshold for satisfactory security. Certainly more restrictive
policies might reasonably be used, but any policy less restrictive
than the approach described below is very likely to result in
significant security issues.
To recap, we have five defense mechanisms available at the
application level:
1. Identity -- know who the request came from.
Willis & Allen Expires December 14, 2007 [Page 19]
Internet-Draft SIP Answering Modes June 2007
2. Alerting -- Let the called user know what's happening. Some
applications might use inbound media as an alert.
3. Acceptance -- Require called user to make run-time decision.
Asking the user to make a run-time decision without alerting the
user to the need to make a decision is generally infeasible.
This will have implications for possible alerting options that
are outside the scope of this document.
4. Limit the I/O -- Turn off loudspeakers or microphone. This could
be used to convert a bidirectional media session (very risky,
possible "bug")into a unidirectional inbound-only (less risky,
possible "spam") session while waiting for user acceptance.
5. Policy -- rules about other factors, such was black and
whitelisting based on identity, disallowing acceptance without
alerting, etc.
Since SIP and related work already provide several mechanisms
(including SIP Digest Authentication [RFC3261], the SIP Identity
mechanism [RFC4474], and the SIP mechanism for asserted identity
within private networks [RFC3325], in networks for which it is
suitable) for establishing the identity of the originator of a
request, we presume that an appropriately selected mechanism is
available for UAs implementing the extensions described in this
document. In short, UAs implementing these extensions MUST be
equipped with and MUST exercise a request identity mechanism. The
analysis below proceeds from an assumption that the identity of the
sender of each request is either known or is known to be unknown, and
can therefore be considered in related policy considerations.
Failure to meet this identity requirement either opens the door to a
wide range of attacks, or requires operational policy so tight as to
make these extensions useless.
We previously established a class distinction between inbound and
outbound media flows, and can model bidirectional flows as "worst
case" sums of the risks of the other two classes. Given this
distinction, it seems reasonable to provide separate directionality
policy classes for:
1. Inbound media flows.
2. Outbound media flows.
For each directionality policy class, we can divide the set of
request identities into three classes:
Willis & Allen Expires December 14, 2007 [Page 20]
Internet-Draft SIP Answering Modes June 2007
1. Identities explicitly authorized for the class.
2. Identities explicitly denied for the class.
3. Identities for which we have no explicit policy and need the user
to make a decision.
7.4. Minimal Policy Requirement
User agents implementing this specification SHOULD NOT establish a
session providing inbound media without explicit user acceptance
where the requesting user is unknown, or is known and has not been
granted authorization for such a session. This requirement is
intended to prevent "SPAM broadcast" attacks" where unexpected and
unwanted media is played out at a UAS .
User agents implementing this specification MUST NOT establish a
session providing outbound or bidirectional media sourced from the
user agent without explicit user acceptance. Loopback media used for
connectivity testing is not constrained by this requirement. This
requirement is intended to assure that this extension can not be used
to turn a UAS into a remote-controlled microphone (or "bug") without
the knowledge of its user.
8. IANA Considerations
8.1. Registration of Header Fields
This document defines new SIP header fields named "Answer-Mode" and
"Priv-Answer-Mode".
The following rows shall be added to the "Header Fields" section of
the SIP parameter registry:
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| Answer-Mode | | [RFCXXXX] |
| Priv-Answer-Mode | | [RFCXXXX] |
+------------------+--------------+-----------+
Editor Note: [RFCXXXX] should be replaced with the designation of
this document.
Willis & Allen Expires December 14, 2007 [Page 21]
Internet-Draft SIP Answering Modes June 2007
8.2. Registration of Header Field Parameters
This document defines parameters for the header fields defined in the
preceding section. The header fields "Answer-Mode" and "Priv-Answer-
Mode" can take the values "Manual" or "Auto".
The following rows shall be added to the "Header Field Parameters and
Parameter Values" section of the SIP parameter registry:
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| Answer-Mode | Manual | No | [RFCXXXX] |
| Answer-Mode | Auto | No | [RFCXXXX] |
| Priv-Answer-Mode | Manual | No | [RFCXXXX] |
| Priv-Answer-Mode | Auto | No | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
Editor Note: [RFCXXXX] should be replaced with the designation of
this document.
8.3. Registration of SIP Option Tags
This document defines the SIP option tag "answermode".
The following row shall be added to the "Option Tags" section of the
SIP Parameter Registry:
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| answermode | This option tag is for support of the | [RFCXXXX] |
| | Answer-Mode and Priv-Answer-Mode | |
| | extensions used to negotiate automatic | |
| | or manual answering of a request. | |
+------------+------------------------------------------+-----------+
Editor Note: [RFCXXXX] should be replaced with the designation of
this document.
9. Acknowledgements
This document draws requirements and a large part of its methodology
from the work of the Open Mobile Alliance, and specifically from an
internet draft by Andrew Allen, Jan Holm, and Tom Hallin.
The editor would also like to recognize the contributions of David
Willis & Allen Expires December 14, 2007 [Page 22]
Internet-Draft SIP Answering Modes June 2007
Oran and others who argued on the SIPPING mailing list and at the OMA
ad-hoc meeting at IETF 62 that the underlying ideas of the above
draft were broadly applicable to the SIP community, and that the
concepts of alerting and answering should be clearly delineated.
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.
[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.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
10.2. Informative References
[I-D.ietf-mmusic-media-loopback]
Hedayat, K., "An Extension to the Session Description
Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-06 (work in progress),
April 2007.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
and B. Rosen, "Change Process for the Session Initiation
Willis & Allen Expires December 14, 2007 [Page 23]
Internet-Draft SIP Answering Modes June 2007
Protocol (SIP)", BCP 67, RFC 3427, December 2002.
Authors' Addresses
Dean Willis (editor)
Unaffiliated Individual
3100 Independence Pkwy #311-164
Plano, Texas 75075
USA
Phone: unlisted
Fax: unlisted
Email: dean.willis@softarmor.com
Andrew Allen
Research in Motion (RIM)
122 West John Carpenter Parkway, Suite 430
Irving, Texas 75039
USA
Phone: unlisted
Fax: unlisted
Email: aallen@rim.com
Willis & Allen Expires December 14, 2007 [Page 24]
Internet-Draft SIP Answering Modes June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Willis & Allen Expires December 14, 2007 [Page 25]
