Re: [secdir] SECDIR review of draft-worley-service-example-13

worley@ariadne.com (Dale R. Worley) Mon, 16 September 2013 21:38 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B8211E81CF for <secdir@ietfa.amsl.com>; Mon, 16 Sep 2013 14:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.833
X-Spam-Level:
X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsgbYpockMF9 for <secdir@ietfa.amsl.com>; Mon, 16 Sep 2013 14:38:03 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D09B211E8113 for <secdir@ietf.org>; Mon, 16 Sep 2013 14:38:02 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r8GLb99j016883; Mon, 16 Sep 2013 17:37:11 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r8GLb8XV1255150; Mon, 16 Sep 2013 17:37:08 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r8GLb3Tl1255783; Mon, 16 Sep 2013 17:37:03 -0400 (EDT)
Date: Mon, 16 Sep 2013 17:37:03 -0400
Message-Id: <201309162137.r8GLb3Tl1255783@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Stephen Kent <kent@bbn.com>
In-reply-to: <52163380.5070005@bbn.com> (kent@bbn.com)
References: <52163380.5070005@bbn.com>
X-Mailman-Approved-At: Mon, 16 Sep 2013 14:53:16 -0700
Cc: mary.ietf.barnes@gmail.com, gonzalo.camarillo@ericsson.com, fluffy@iii.ca, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-worley-service-example-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2013 21:38:09 -0000

This is a report on changes to draft-worley-service-example (to
produce draft-worley-service-example-14) in response to the SECDIR
review by Stephen Kent.

> Date: Thu, 22 Aug 2013 11:51:28 -0400
> From: Stephen Kent <kent@bbn.com>

> This document describes how to provide music on old (MOH) in a VoIp 
> environment, an obviously critical capability needed to preserve feature 
> compatibility with the PSTN. Callers who are not subjected to MOH might 
> otherwise not be exposed to classical music, in many contexts, a tragic 
> outcome.

Unfortunately, the real market driver for MOH is businesses that want
to play ads to you while you are waiting on hold to talk to a human.
Creating a facility to allow these businesses to do what they want
might be considered as violating the "Do no evil." principle, but it
does seem to be critical in the marketplace.

> I was surprised to see that all the references to RFCs (normative
> and informative) use labels other than RFC numbers. This an unusual
> convention that I hope the RFC editor will fix.

Personally, I find it a lot more convenient to tag RFCs by their
topics than their numbers, as I don't remember the numbers of more
than a handful of RFCs.  Nonetheless, using RFC numbers as tags is the
convention these days, and I've updated the draft to do the same.

> It is hard to overstate the importance of appropriate security 
> mechanisms for this critical aspect of VoIP. Consistent with this 
> observation, the Security Considerations section of this document 
> consists of just one paragraph. The paragraph addresses one security 
> concern, i.e., the ability of the UA of a caller to filter incoming 
> media based on the address of the source of the media. The design in 
> this document provides the source address of the MOH server, via SDP (in 
> a re-INVITE), to the caller who is on hold, and thus satisfies this concern.
> 
> In a more serious vein, I'd like to see the Security Considerations 
> section mention whether UAs are expected to use SDP and SIP security 
> mechanisms for MOH, IF these mechanisms were employed for the original 
> call. Another paragraph could be added to discuss the desirability of 
> maintaining an equivalent level of security when a caller is switched 
> over to MOH, and to cite the relevant RFCs, or to explain why this is 
> not appropriate.

I've expanded the draft in this regard.  The new text is:

    5.  Security Considerations

    5.1.  SIP (signaling) security

       The executing UA and the MOH server will usually be within the same
       administrative domain and the SIP signaling path between them will
       lie entirely within that domain.  In this case, the administrator of
       the domain should configure the UA and server to apply to to the
       dialog between them a level of security that is appropriate for the
       administrative domain.

       If the executing UA and the MOH server are not within the same
       administrative domain, the SIP signaling between them should be at
       least as secure as the SIP signaling between the executing UA and the
       remote UA.  Thus, the MOH server should support all of the SIP
       security facilities that are supported by the executing UA, and the
       executing UA should use in its dialog with the MOH server all SIP
       security facilities that are used in its dialog with the remote UA.

    5.2.  RTP (media) security

       The RTP for the MOH media will pass directly between the MOH server
       and the remote UA, and thus may pass outside the administrative
       domain of the executing UA.  While it is uncommon for the contents of
       the MOH media to be sensitive (and the remote UA will not usually be
       generating RTP when it is on-hold), the MOH RTP should be at least as
       secure as the RTP between the executing UA and the remote UA.  In
       order to make this possible, the MOH server should support all of the
       RTP security facilities that are supported by the executing UA.

       It is possible that the remote UA and the MOH server support an RTP
       security facility that the executing UA does not support, and that it
       is desirable to use this facility for the MOH RTP.  To enable this,
       the executing UA should the SDP between the remote UA and the MOH
       server completely, not omitting elements that it does not understand.

    5.3.  Media filtering

       Some UAs filter incoming RTP based on the address of origin as a
       media security measure.  The remote UA in the original dialog may use
       this media filtering, and if the executing UA does not update the SDP
       to inform the remote UA of the source address of the MOH media, the
       remote UA may not render the MOH media.  Note that the executing UA
       has no means for detecting that the remote UA uses media filtering,
       so the executing UA must assume that any remote UA uses media
       filtering.

       The technique described in this document ensures that any UA that
       should render MOH media will be informed of the source address of the
       media via the SDP that it receives.  This allows such UAs to filter
       media without interfering with MOH operation.

Dale