Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 19 April 2016 08:03 UTC
Return-Path: <magnus.westerlund@ericsson.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 8B10612DCCA; Tue, 19 Apr 2016 01:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnKCbJ51_F5w; Tue, 19 Apr 2016 01:03:22 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9FD12DDEE; Tue, 19 Apr 2016 01:03:20 -0700 (PDT)
X-AuditID: c1b4fb2d-f79006d000006928-c8-5715e646c5fe
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.38.26920.646E5175; Tue, 19 Apr 2016 10:03:18 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 19 Apr 2016 10:03:05 +0200
To: Ben Campbell <ben@nostrum.com>
References: <alpine.BSF.2.20.1604150753390.94067@fledge.watson.org> <5714A9D6.4010602@ericsson.com> <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <5715E637.7070004@ericsson.com>
Date: Tue, 19 Apr 2016 10:03:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2K7ja7bM9FwgzU7FSw+3rvBajG/8zS7 xYwpB5gtZvyZyGzxYeFDFosJr6czObB5LFnyk8lj1s4nLB5LG3azBzBHcdmkpOZklqUW6dsl cGVMmtPCVnBRsWLz2aNsDYz/pLoYOTkkBEwkFh9ZwgJhi0lcuLeerYuRi0NI4AijxIuLW1kh nOWMElf3XQSrEhawkTh77yo7iC0ioCTxvHkrC0TRLEaJg2+7wRxmgWWMElvnb2MGqWITsJC4 +aORDcTmFdCWeLPjMiOIzSKgKnG77R9YXFQgRqLxwSkmiBpBiZMzn4Bt4xSwl/h2bCnQGRxA Q+0lHmwtAwkzC8hLNG+dDTZeCGhkQ1MH6wRGwVlIumchdMxC0rGAkXkVo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmCIH9zyW3cH4+rXjocYBTgYlXh4FSaKhguxJpYVV+YeYpTgYFYS4Q17 DBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOmxP5L0xIID2xJDU7NbUgtQgmy8TBKdXAKFP/fE1u 0K1bvRktqdUNFtfkeNwOZSydYMIYk1HKUP/orPSlm7ZxOd3NBy65lNhJa8UZ/n3t/Pq96YzJ J56lXljFsENGeWIN5/xVvTc//dtw5OnDznmh8WxvjtrduWvLqlOau91Ocf3jf4vXFc/hflfN Yie3fGO1h3NUO5fSmtUnZqSrTvVWVWIpzkg01GIuKk4EABEFE9VtAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Yhhac7ZE-9r9z3-ZkizUB1X_d9Y>
Cc: iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" <avtext@ietf.org>, Samuel Weiler <weiler+ietf@watson.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Apr 2016 08:03:25 -0000
Den 2016-04-18 kl. 16:29, skrev Ben Campbell: > On 18 Apr 2016, at 4:33, Magnus Westerlund wrote: > >> Hi Samuel, >> >> (CC the WG) >> >> Thanks for the review. >> >> Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: >>> 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. >>> >>> >>> I am mostly satisfied with this document's security analysis. I am >>> worried that implementors will weasel their way around the "SHOULD"s, >>> but the appropriate "SHOULD"s are in the doc. >>> >>> The doc says "...there SHOULD be strong integrity protection and source >>> authentication of the header extensions" -- I would like to also see >>> specific citation(s). (e.g. "Use X for integrity protection." "Use X >>> for authenticity.") >> >> So I will claim that the common problem that exists with minor RTP >> extension and RTP payload formats (see RFC 7202) do apply here, we >> should at least reference RFC 7201 for the options in the security >> consideration section. >> >> I will edit our source and likely push out such a change quite soon so >> that it is in place in good time before the IESG call. Unless our AD >> objects. >> >> I propose to add the below to end of the last paragraph. >> >> "For information regarding options for securing RTP, see [RFC7201]." >> >> And add RFC7201 as an informative reference. > > The AD does not object. I think it makes sense to treat this similarly > to how we treat payload drafts. > > >> >>> >>> It would be nice to see some discussion of whether these headers >>> increase the utility of RTP as a DOS vector - either by enabling a >>> reflector attack or by triggering heavy computation on a receiving >>> host. I suspect that there's not much to see here, particularly if >>> there really is integrity protection, but it would be nice to see the >>> analysis. >> >> Yes, this is a reasonable thing to consider. I suggest that we add the >> below paragraph before the last paragraph in the Security Consideration. >> >> The general RTP header extension mechanism does not itself contain any >> functionality that is a significant risk for a denial of service >> attack, nor from processing or storage requirements. This specific >> extension for SDES items, could potentially be a risk. > > Do you mean that _this_ extension might be a risk, or that any specific > SDES item might be a risk? The sentence sounds like it means the former, > but the rest of the paragraph suggests the latter. So the SDES item header extension in its basic mechanism does not appear to be a risk. However, the semantics of the SDES item itself may be a cause for concerns. It is really the next sentence below that attempts to clarify from where this risk comes. I will try to wordsmith this with help of my co-authors. > >> If the received SDES item and its content causes the receiver to >> perform larger amount of processing, create significant storage >> structures, or emit more network traffic such a risk do exist. The >> CNAME SDES item is only a minor risk as reception of a CNAME item will >> create an association between the stream carrying the SDES item and >> other RTP streams with the same SDES item. As this can result in time >> synchronizing the media streams some additional processing may result. >> However, the applications media quality appear will be likely more >> affected of the wrongly or changing association, than from the impact >> caused by the additional processing. >> Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [secdir] secdir review of draft-ietf-avtext-sdes-… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-avtext-s… Magnus Westerlund
- Re: [secdir] secdir review of draft-ietf-avtext-s… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-avtext-s… Ben Campbell
- Re: [secdir] secdir review of draft-ietf-avtext-s… Magnus Westerlund