[AVTCORE] SRTP: Retransmission or replay attacking? How to discriminate in e2ae environment?
HE Bing <Bing.He@alcatel-sbell.com.cn> Tue, 30 October 2012 05:57 UTC
Return-Path: <Bing.He@alcatel-sbell.com.cn>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D064A21F8551 for <avt@ietfa.amsl.com>; Mon, 29 Oct 2012 22:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.816
X-Spam-Level:
X-Spam-Status: No, score=0.816 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_BACKHAIR_51=1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVIhSSXXtln9 for <avt@ietfa.amsl.com>; Mon, 29 Oct 2012 22:57:17 -0700 (PDT)
Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED2621F853B for <avt@ietf.org>; Mon, 29 Oct 2012 22:57:15 -0700 (PDT)
X-AuditID: ac189297-b7fc36d0000051ff-57-508f6a7d236b
Received: from CNSHJCASHUB03.ad4.ad.alcatel.com (Unknown_Domain [135.251.50.73]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Messaging Gateway) with SMTP id B1.D6.20991.D7A6F805; Tue, 30 Oct 2012 13:49:49 +0800 (HKT)
Received: from CNSHJMBX03.ad4.ad.alcatel.com ([169.254.3.119]) by CNSHJCASHUB03.ad4.ad.alcatel.com ([135.251.50.73]) with mapi id 14.02.0283.003; Tue, 30 Oct 2012 13:57:11 +0800
From: HE Bing <Bing.He@alcatel-sbell.com.cn>
To: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: SRTP: Retransmission or replay attacking? How to discriminate in e2ae environment?
Thread-Index: Ac22Y2h71kEi4I8zTAa8RBawufogKQ==
Date: Tue, 30 Oct 2012 05:57:11 +0000
Message-ID: <DE315914FFC19345B99B2A4B7F595ED00E426885@CNSHJMBX03.ad4.ad.alcatel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.143.123]
Content-Type: multipart/alternative; boundary="_000_DE315914FFC19345B99B2A4B7F595ED00E426885CNSHJMBX03ad4ad_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42Jp/60opVub1R9g0NVkbvGyZyW7A6PHkiU/ mQIYo7hsUlJzMstSi/TtErgybs9dz1jwRLLiQcsmxgbGe6JdjJwcEgImEt83XGWHsMUkLtxb z9bFyMUhJHCHUeLkl3nsEM5WRok356eDVbEJ6Eh0Pm9jA7FFBBQlWq99ZgSxhQViJfYuaYaK J0k0X78EZetJ7Hj8BayGRUBVYveNF0wgNq9AiMS8j/0sIDajgKzEtEf3weLMAuISt57MZ4K4 SEBiyZ7zzBC2qMTLx/9YIWwlid5bP9kg6vMlZvw8wQYxU1Di5MwnLBA1khIHV9xgmcAoPAvJ 2FlIWmYhaYGI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGBWS84ozsopzM/MMDPUSc5IT S1JzdIuTUnNy9JLzc/WS8zYxAmNojcSk6TsYd+23PMQowMGoxMO7YU1fgBBrYllxZe4hRgkO ZiUR3nzv/gAh3pTEyqrUovz4otKc1OJDjNIcLErivJmbiwOEBNKBZmenphakFsFkmTg4pRoY 1a9Ouu/zXLnko+FUrS282kLT49/P8xHa5rDzeP+fv8VPCybGxTFPWbdNXTbuKLezbpYxW2q6 +Ie/3F5qHxQUf8qlu3AHamU9XlO3KiAvqibfY49K+xomDsbNZ4J/2n9Un9i+22Cf/bmbvjb7 V5h/8TbafzzOq81c6dbT7vdJUi6v9qh+Kn2jxFKckWioxVxUnAgAAK7frJ0CAAA=
Subject: [AVTCORE] SRTP: Retransmission or replay attacking? How to discriminate in e2ae environment?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2012 05:57:17 -0000
Dear all, RTP/SAVTF is adopted in WebRTC. For video stream, SRTP sender will do retransmission for the SRTP packets indicated by RTCP FB NACK packets. The retransmitted SRTP packets are exactly identical to the original packets (one exception is Google Chrome WebRTC use RTP header extension per RFC 5450 so that every retransmitted SRTP packet has different header extension from the original one) Now we see a problem in valid e2ae environment that can be simplified as below: A (Browser)<---(SRTP, SRTCP)--->IMS boder<---((RTP, RTCP)--->B (IMS client) Where IMS border works in RTP transparent forwarding mode with additional encryption/decryption on browser side. If an A party originated packet was lost on the way from IM border to B party, this packet will be marked as received in IMS border SRTP replay-check list. Upon receipt of the RTCP FB NACK packet originated by B party, A will resend the packet which will be discarded by IMS border when doing replay checking job. Is there any way to resolve this issue? Thanks and best regards! He Bing