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
- [secdir] SECDIR review of draft-worley-service-ex… Stephen Kent
- Re: [secdir] SECDIR review of draft-worley-servic… Dale R. Worley