Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)
draft-lehtovirta-srtp-rcc-06

[Ballot comment]
It's unfortunate that this integrity transform needs to be coupled to
a choice of hash.  That means that in the future we'll end up with a
lot of integrity transforms if we need new hashes.  However that seems
like the best design tradeoff available to us.

[Ballot discuss]
Section 2, second paragraph:

  Next the sender
  constructs the tag as TAG = ROC_sender || MAC, where ROC_sender is
  the value of his local ROC, and appends the tag to the packet.

In this paragraph it is not made clear that the TAG generated has the same length as the TAG for Seq !=0 mod R. In my opinion there is needed a statement to indicate that the MAC concatenated with the ROC_sender value is in fact truncated with 4 bytes.

[Ballot discuss]
I suspect that I am wrong about this and that there is a reasons it is not an issue (and I will clear the discuss). If an attacker has an very old packet they captures with an old ROC, and they send it to the receiver, it seems like would update the ROC to old one and then all new packets would be discarded until a new R=0 was reached. This would kill quality of the stream and defeat the SRTP goals of the integrity protections.

I am concerned on who has reviewed this - the rtpsec mailing would not be the best place to review a change to SRTP which this basically is. I can not find a single post on an IETF list that indicates that anyone read this. Again, I suspect I am just missing stuff here and glad to clear if it has been reviewed by people that understand SRTP really well.

[Ballot comment]
The write-up mentions that 'The RoC is carried in every rth packet, which is bandwidth-sensitive'. I cannot find any mention in the document about this issue. Is there any impact on the applications or network operation, like an increase in bandwidth consumption to care about, or is this only about consuming a number of bits in the header to carry the RoC?

IANA Last Call Comments:

All assignments in registry http://www.iana.org/assignments/mikey-payloads

First assignment
Upon approval of this document, the IANA will make the following assignments
in the "Mikey Payload Name Spaces" registry located at http://www.iana.org/
assignments/mikey-payloads
in table "SRTP auth alg" add
SRTP auth alg | Value
--------------+------
RCCm1 | 2 [RFC-srtp-rcc]
RCCm2 | 3 [RFC-srtp-rcc]
RCCm3 | 4 [RFC-srtp-rcc]

Note: IANA considerations section requests names RCCv1 please advise which
name to use.


Second assignment:
Upon approval of this document, the IANA will make the following assignments
in the "Mikey Payload Name Spaces" registry located at http://www.iana.org/
assignments/mikey-payloads in table "SRTP"

13 ROC transmission rate [RFC-srtp-rcc]
14 SRTP Auth. algorithm [RFC-srtp-rcc]
15 SRTCP Auth. algorithm [RFC-srtp-rcc]
16 SRTP Session Auth. key len [RFC-srtp-rcc]
17 SRTCP Session Auth. key len [RFC-srtp-rcc]
18 SRTP Authentication tag len [RFC-srtp-rcc]
19 SRTCP Authentication tag len[RFC-srtp-rcc]

This concludes the assignments.