Subject: [AVTCORE] SRTP: Retransmission or replay attacking? How to discriminate in e2ae environment?

From: HE Bing <[email-masked]>
Date: Tue, 30 Oct 2012 05:57:11 +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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Oct 2012 10:06:33 +0100

On 2012-10-30 06:57, HE Bing wrote:
> 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)

I would like to point out that for RTP retransmission it is expected
that RFC 4588 is used for the retransmitted packets. That specification
exist to address the issue that retransmitting an RTP packet as an
identical copy doesn't work as it destroys all the statistics and
tracking of packets as well as the below SRTP replay issue.

> *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.
>  

Use RFC 4588 retransmission payload and this issue goes away.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: HE Bing <[email-masked]>
Date: Wed, 31 Oct 2012 06:59:34 +0000

Thank Magnus for your quick help! 
I found relevant statement in draft-ietf-rtcweb-rtp-usage-04.txt too.
Best regards!
HE Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Tuesday, October 30, 2012 5:07 PM
To: [email-masked]
Subject: Re: [AVTCORE] SRTP: Retransmission or replay attacking? How to discriminate in e2ae environment?

On 2012-10-30 06:57, HE Bing wrote:
> 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)

I would like to point out that for RTP retransmission it is expected that RFC 4588 is used for the retransmitted packets. That specification exist to address the issue that retransmitting an RTP packet as an identical copy doesn't work as it destroys all the statistics and tracking of packets as well as the below SRTP replay issue.

>  
> Now we see a problem in valid e2ae environment that can be simplified 
> as
> below:
> (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.
>  

Cheers

Magnus Westerlund

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt