Re: [secdir] Secdir review of draft-ietf-mmusic-sdp-bundle-negotiation-48

Christer Holmberg <> Sun, 11 February 2018 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00880126DEE for <>; Sun, 11 Feb 2018 08:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x3BcM2cIKsAD for <>; Sun, 11 Feb 2018 08:25:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 545121201F2 for <>; Sun, 11 Feb 2018 08:25:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1518366352; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rhOy3brmOvzpNh7LlP/ZTxv0fiM34g7QTFhoeUEim6Y=; b=O1ihiI3Mu6YoG3u8KqX/kn9FEw31HuRDFAW9V2h33SwDGKPoav+byzijpyYPG871 +5rwpk9llOG30jJl+QuPMWkuQiGSdPyqj47Mswx3xDMCNNRM8ub+1HBhURifw4tA Fb5OSgLLp0FNfy84lU1mKf6PiImG8cF0ykK2gajJzS8=;
X-AuditID: c1b4fb30-399ff70000004778-b5-5a806e906808
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F9.2B.18296.09E608A5; Sun, 11 Feb 2018 17:25:52 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0352.000; Sun, 11 Feb 2018 17:25:51 +0100
From: Christer Holmberg <>
To: Charlie Kaufman <>, "" <>, "" <>, "" <>
Thread-Topic: Secdir review of draft-ietf-mmusic-sdp-bundle-negotiation-48
Thread-Index: AQHTovy5RO7AatX+n0q+gBTE9V2YxKOfX5OA
Date: Sun, 11 Feb 2018 16:25:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C165419ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7h+6EvIYog2XfRCym/T7BYnHi/TdW ixl/JjJbfFj4kMWBxWPJkp9MHptfv2AOYIrisklJzcksSy3St0vgyrjSu52l4FJmxa/zC9kb GE/GdDFyckgImEjcPnyYrYuRi0NI4DCjxM7XzxkhnCWMEtt+/wNyODjYBCwkuv9pg8RFBN4y Svx5PZ0ZpFtYwFOitekvM0iNiICXxM7djiBhEQEjie2v97CD2CwCqhK7Tu5jArF5BXwlzk8+ zwhiCwnESBxcBRHnFIiVmN9+mQ3EZhQQk/h+ag1YnFlAXOLWk/lMEIcKSCzZc54ZwhaVePn4 HyuErSSxYvslRoj6fIme359YIXYJSpyc+YRlAqPwLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC 18ww9pkDj5mQxRcwsq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIypg1t+G+xgfPnc8RCj AAejEg9vq2pDlBBrYllxZe4hRgkOZiUR3hspQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Jz15 o4QE0hNLUrNTUwtSi2CyTBycUg2Mqj6S9xSn7zi5vebQfPNvUr9XOV9p+m5Vdvemym6nFes+ 1nO0q55atXujanTAfIud7/6mKMy2CPy24fHT376ntK5nivHe2Hh0s+9M93SJXYkOScs23vtm 6jbNaeEOobXhYttj2uuP3vnpkDX7itP+B/Oc3Cb93sAbXpJVZnxg5lVDJqOw78ZiX5VYijMS DbWYi4oTAdx56E2lAgAA
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-sdp-bundle-negotiation-48
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Feb 2018 16:25:57 -0000

Hi Charlie,

Thanks for your review! Please see inline.

>I have 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.


>This specification defines an enhancement to the RTP Control Protocol (RTCP) defined in RFC3264. The enhancement allows multiple items over a single >RTP channel with interleaved packets. This is harder than one would expect in part because the protocol change has to deal with backward compatibility >and interoperability between implementations that include the enhancement and those that don't.


>While I can't claim to have understood the entire spec, I can confidently agree with the authors that this enhancement does not change the security >considerations from those specified in RFCs 3264 and 5888.


>Other thoughts:


>The use of the term "Unique Address" for the combination of an IP address and a port number is a little confusing, especially when interleaved with >references to 5-tuples as connection identifiers. Since this protocol is always (?) transmitted over UDP, it would be good to mention somewhere that two >unique addresses together make a connection identifier (where UDP is implied) and that a Unique Address is the combination of an IP address and a UDP >port number.

"Unique Address" will be changed to "Unique Address:Port", similar to e.g., "BUNDLE Address:Port". The definition already indicates that it includes the port:

      "Unique address: An address:port combination that is assigned to only one "m=" section in an offer or answer."

> Given the large numbers of NATs out there, I'm surprised the protocol does not make itself a little more NAT friendly by

> allowing an address specification with an ability to specify "The IP address from which this message is arriving" so that

> NAT'd connections will be handled correctly (at least in the most common case).

In SDP Offer/Answer (RFC 3264) you always indicate the address:port where you will RECEIVE media. That has caused some problems every now and then, but it's not within the scope of the draft to change that.

However, BUNDLE actually mandates usage of the SAME address:port for both sending AND receiving media, so in practise you DO indicate from where media will be sent :)

>Section 18 (examples) is a very welcome addition that I wish were present in more RFCs. It goes a

>long way toward making otherwise difficult to parse sections of the document more comprehensible.

Good :)

It is also worth noting that, as BUNDLE is an extension to RFC 3264 (SDP Offer/Answer), one needs to be familiar with that specification in order to fully understand BUNDLE.