Subject: [AVT] Comments on draft-ietf-avt-srtp-03.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Mar 2002 00:21:39 -0600

I have a number of technical comments on the latest SRTP draft, if the
authors would like to comment:

- It is not clear where RTP padding is inserted, if required. Does it go
  at the end of the payload (just before the optional SRTP headers) or at
  the end of the packet? (also for RTCP padding)

- How does the rollover counter change if an SSRC collision occurs? Does
  it get reset to zero (since presumably the sequence number and timestamp
  will be reset to a random value when the source changes its SSRC)?

- In section 3.2.1, is it necessary to specify robust rules for updating
  the ROC at the receiver? Does anything break if the receiver gets it
  wrong? RTP has a robust algorithm, if necessary.

- The last paragraph of section 3.2.1 may wish to refer to the discussion
  of sequence numbers in RTP spec, which has similar comments.

- A number of fields, for example the ROC, need to be signalled. How is
  this done? Should this draft define the parameters that need to be
  signalled, and their mapping to SDP? It may be appropriate to list the
  parameters that are required, even if they're not defined here.

- I don't understand (near the end of section 3.3):
	As noted, the encryption prefix (Section 6.1 of [RFC1889]),
	is not to be used because this mechanism supports ciphers
	that are not secure against known plaintext attacks.  Ciphers
	that are not secure against known-plaintext attacks SHOULD not
	be used to encrypt RTP messages. The pre-defined SRTP
	encryption uses a secure, additive stream cipher, and thus
	the prefix offers no benefit at all.
  This is saying the prefix is not used because ciphers that are not secure
  are used?

- You say (also in section 3.3):
	"However, when adding authentication to RTCP, the overhead in
	bandwidth SHOULD be considered (the bandwidth will be more than
	5%)"
  I would have expected that SRTCP rate to be calculated including any
  extra header/authentication fields? How does possible packet expansion
  affect the RTP/RTCP bandwidth calculations? (e.g. RTCP packet timing,
  SR octet count).

- I'm not entirely comfortable with the definition of TMMH being in this
  draft. Consider splitting it into a separate RFC, to make this draft
  independent of the specification of any particular MAC code.

- If it is necessary to setup IANA registry for the algorithms and modes,
  this draft needs to provide the necessary guideance.

- Please comment further on the security benefits of using key derivation
  from the master key. I have trouble understanding how it helps security, 
  although I can see the rationale for saving on key distribution. 

- The security of the system depends on the SSRC being unique. This
  is okay, but you must specify exactly what happens when an SSRC
  collision occurs. Especially since you can't tell if a collision
  will occur until after you've sent a packet, and hence revealed
  they key.

I also have a number of editorial comments, which I will send off list.

Cheers,
Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt