[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Question regarding RFC 3711

I'm forwarding this message to the list. It seems to have been sent to avt-bounces at ietf.org (which route to us list administrators) rather than to avt at ietf.org. 

Tom T

Subject:
RE: Question regarding RFC 3711
From:
Ilan Doron <Ilan.Doron at audiocodes.com>
Date:
Wed, 8 Jul 2009 11:08:46 +0300
To:
"avt-bounces at ietf.org" <avt-bounces at ietf.org>, "Wyss, Felix" <Felix.Wyss at inin.com>

Hi
In our case the new keys are received from a re invite session done by the SIP (or any control protocol). 
No multiple keys so I believe MKI is not relevant.
It seems state is ambiguous:
If considered as re-keying ROC should be kept. Otherwise ROC should be zeroed.

Am I getting this right?

From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Wyss, Felix
Sent: Monday, July 06, 2009 8:28 PM
To: Ilan Doron; 'avt at ietf.org'
Subject: Re: [AVT] Question regarding RFC 3711

[inline]

From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ilan Doron
Sent: Monday, July 06, 2009 10:23
To: 'avt at ietf.org'
Subject: [AVT] Question regarding RFC 3711

I have a few questions regarding rfc 3711:

>From the RFC, section 3.3.1:
After a re-keying occurs (changing to a new master key), the rollover
   counter always maintains its sequence of values, i.e., it MUST NOT be
   reset to zero.


1.       Does re-keying include reinvite session where new keys are allocated?
[Wyss, Felix] Not necessarily. If multiple master keys were supplied as part of the key distribution, the sender can switch between them arbitrarily and indicate which one is used for that packet by means of the MKI.
2. If ROC is maintained, can I assume full SRTP session is maintained, i.e. RTP sequence + replay lists + SSRC? [Wyss, Felix] As SRTP is just a bump in the stack, changes of the SSRC are not under the SRTP sender's control. For a particular SSRC, the SRTP sender needs to maintain the appropriate state for a cryptographic context, including the ROC. How many contexts the SRTP sender maintains depends on the application (e.g. how many concurrent streams may have to be processed). 

Regarding SSRC change during SRTP session:
1. If a new SSRC arrives should the packet be authenticated with a zero ROC or with the current ROC value? [Wyss, Felix] Each context starts at a ROC of zero. If you might be joining streams late, you can of course try authenticating a couple of ROCs for added robustness (but potentially increased denial of service risk).
2. Assuming authentication succeeds, SRTP session will be reset to zero (Sequence, replay lists ROC etc.)? [Wyss, Felix] A new SSRC gets a new crypto context. You will want to maintain at least as many contexts as there may be concurrent streams being processed plus a couple of spares to deal with periods of overlapping streams when you switch between devices. 

Ilan Doron
Media application Team Leader
Tel:         +972-3-9764354
Fax:        +972-3-9764223
Mobile:   +972-54-6262-775
Email:     iland at audiocodes.com<mailto:iland at audiocodes.com>
<mailto:Golan.Buznak at audiocodes.comWeb>Web: www.audiocodes.com<http://www.audiocodes.com/> 

[cid:image001.jpg@01C9FFBC.665375D0]<http://www.audiocodes.com/solutions/hdvoip>
Click to Sign Up for our email updates<http://www.mymarketing.co.il/Subscribe.htm?_u=f3j2a8> 


________________________________
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message 

________________________________
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message