[secdir] review of draft-ietf-mmusic-connectivity-precon-06

Stephen Kent <kent@bbn.com> Thu, 08 October 2009 10:42 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA2F3A6A5D for <secdir@core3.amsl.com>; Thu, 8 Oct 2009 03:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level:
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7gm5BjQExWO for <secdir@core3.amsl.com>; Thu, 8 Oct 2009 03:41:58 -0700 (PDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4B15E28C138 for <secdir@ietf.org>; Thu, 8 Oct 2009 03:41:57 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1MvpX3-0007oT-Et; Thu, 08 Oct 2009 05:43:35 -0400
Mime-Version: 1.0
Message-Id: <p06240808c6f371223391@[193.0.26.228]>
Date: Thu, 08 Oct 2009 06:40:31 -0400
To: fandreas@cisco.com, Gonzalo.Camarillo@ericsson.com, oran@cisco.com, dwing@cisco.com
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-957123881==_ma============"
Cc: fluffy@cisco.com, rjsparks@nostrum.com, secdir@ietf.org
Subject: [secdir] review of draft-ietf-mmusic-connectivity-precon-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 08 Oct 2009 10:42:02 -0000

I reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document "draft-ietf-mmusic-connectivity-precon-06" defines "a 
new connectivity precondition for the Session Description Protocol 
(SDP) precondition framework." Connectivity preconditions are used to 
delay session establishment (or modification) until media stream 
connectivity has been verified. The use of preconditions represents 
an interesting twist on the original SDP model, where the assumption 
was that an SDP session would be established before media streams 
were established! The use of preconditions is motivated in large part 
by the need for media streams to traverse firewalls and NATs.

The Security Considerations section here starts by citing the 
Security Considerations section from the base preconditions RFC 
(3312). It also adds two paragraphs to discuss new considerations 
relevant to the precondition types defined in this document. This is 
an appropriate way to address new security issues that arise for 
extensions to previously-defined functions. RFC 3312 has a 
two-paragraph Security Considerations section, which identifies 
concerns, but make no recommendations about security mechanisms to 
employ! This document has a paragraph that RECOMMENDS use of 
integrity for the SDP traffic, e.g., via RFC 3261, to counter attacks 
against this portion of the system. This is a concrete recommendation 
that is appropriate for this aspect of the security concerns cited, 
and is applicable to the 3312 security concerns as well.

The new security concerns that arise here result from reliance on 
other protocols to detect successful media stream establishment. This 
motivates concerns about two classes of DoS attacks: transient 
attacks that cause session establishment to fail (when the media 
streams could have been created) and transient attacks that make it 
appear that media streams have been established, when in fact they 
have not.

TCP and ICE are the protocols cited specifically as one of interest. 
The text RECOMMDNDS making use of suitable authentication and 
integrity mechanisms for the relevant protocols to counter both forms 
of attacks. The text also says that "the mechanisms SHOULD consider 
how to prevent denial of service attacks."

I find this text to be too vague to be useful. It ought to cite 
specific mechanisms in RFCs, at least as examples, preferably as 
recommendations. The lack of specific, cited mechanisms makes this 
section almost vacuous. I suggest that the authors revise the text 
here to cite appropriate mechanisms.