Hi all,
we are doing the final edits to the draft-ietf-avt-rtp-retransmission.
We have considered all your comments until the date, but there's
something for which we would like to get some feedback on: security.
A couple of questions:
1.-As discussed on the list:
...
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
> Perkins
> Sent: Friday, January 10, 2003 4:39 AM
> To: David.Leon@nokia.com
> Cc: avt@ietf.org
> Subject: Re: [AVT] Comments on
> draft-ietf-avt-rtp-retransmission-04.txt
>
...snip...
> >> - In section 12, how does this draft affect SRTP? Is it
> possible to use
> >> the two formats together?
> >
> >We'll try to draft something on that. My understanding is that the
> >retransmission stream is seen as any other stream by SRTP
> and there should
> >thus be no problem.
>
> I was not clear if retransmitting packets caused problems for
> SRTP; maybe
> one of the SRTP authors can comment on any potential security issue?
>
we don't see any problems (except for SRTCP as below in 2) to use SRTP
with RTX since the RTP retransmission packets (with a two byte
retransmission payload header) are seen by SRTP as 'normal' RTP packets.
Is our assumption correct?
2.-The retransmission payload format needs of the AVPF profile to enable
more frequent feedback and to request packets. This profile defines
(besides the new timing rules) some general-purpose messages such as
ACKs and NACKs and a new RTCP packet format: the early feedback packet,
which just contains 1 SR or RR and 1 SDES with just the CNAME. Now,
there should be no problem to encrypt/authenticate early packets,
according to the SRTP draft:
"
According to [RFC1889] there is a "recommended" packet format for
compound packets. SRTCP MUST be given packets according to that
recommendation in the sense that the first part MUST be a sender
report or a receiver report. However, the encryption prefix (Section
6.1 of [RFC1889]), a random 32-bit quantity intended to deter known
plaintext attacks, MUST NOT be used (see below).
"
Also there should be no problem to authenticate/encrypt ACKs and NACKs
with SRTCP since they are sent in compound RTCP packets starting with an
RR or SR packet. Let us know if you disagree with this point.
3.- if a new profile needs be defined, something like "SAVPF", where
shall this profile "SAVPF" be specified and registered? wouldn't it be
reasonable to do this in the SRTP draft which already registers the
"SAVP" profile given that the feedback draft would (presumably) have a
similar schedule to the SRTP draft? In this way the question 2. could
also be anwered there.
4.- the security section in the retransmission draft already points out
the risks of using the same keys across sessions, e.g. two.-time pads
and points to the SRTP for solutions. That much is done. Are we missing
something else?
5.-It is also pointed out that the Timestamp of the retransmission
packets is the same as in the original packets. Since this is random it
should be no problem for security. Is this assumption correct?
Thanks in advance,
José
PS: by the way, in draft-05 Rolf Blom's email is the same as Mark
Baugher's. Probably a cut&paste error.