Subject: [MMUSIC] SSRCs in sdescriptions - the problem and proposed resolution

From: Flemming Andreasen <[email-masked]>
Date: Mon, 29 Dec 2003 21:18:20 -0500

The SDP security descriptions to setup SRTP media stream
(draft-ietf-mmusic-sdescriptions) defines the SRC parameter which
contains the following three fields:

- SSRC:   The SSRC for a crypto context being described.
- ROC:    The roll-over counter for the SSRC
- SEQ:    The RTP sequence number for the SSRC

The SSRC part of this parameter is motivated by two things:
1. Identify the crypto context for which the ROC and SEQ are provided.
2. Prevent SSRC collissions.

Point number two is the problematic one. The reason we want to prevent
SSRC collissions is so we can share a master key without running into
the two-time pad issue. Preventing SSRC collissions through signaling is
however not without problems. In the offer/answer model, the offerer can
include a list of SSRC values, which the answerer can reject in case of
a collission. However, if the answerer includes a list of SSRC values,
the offerer cannot reject those values. Outside of offer/answer, it's
even less clear how this would work.

Possibe solutions include:
1. Get rid of the problem in the first place, i.e. allow for SSRC
collissions. This can be done securely by requiring that the master key
cannot be shared in the send and receive direction. It can be done
somewhat insecurely by accepting the two-time pad problem as a potential
weakness when shared master key(s) are used. The risk of this
happenening is about 2^(-48).
2. Require that SSRC collissions are prevented by means outside the
scope of the protocol. Possible ways of doing this include:
- Central SSRC allocation and distribution of unique SSRCs to the
session participants. This is not a very general solution.
- Forgo the basic property of having negotiation complete in a single
roundtrip, i.e. effectively allow the offerer to accept or deny SSRCs
selected by the answerer. Security preconditions for example can be used
to achieve this. However, this only addresses the problem in the context
of offer/answer and furthermore leads to lengthier negotiation.
3. In the offer/answer model, have the offerer determine the SSRC values
to be used by both the offerer and answerer. If the answerer does not
find these acceptable, he can always reject the offer (and preferably
include a list of acceptable SSRC values).  Apart from the more
philosophical issues of having one party control the SSRCs used by
another party, there is an issue of what the answerer does in case the
offerer did not suggest any SSRCs. As with option 2, this also only
addresses the problem in the context of offer/answer and furthermore can
lead to lengthier negotiation.

The suggestion here is to go with a combination of option 1 and 2:
Master key(s) MUST NOT be shared in the send and receive direction
unless the two parties can guarantee SSRC uniqueness by means outside
the scope of the SDP security descriptions.

Please speak up if you disagree with this and/or if you can think of a
better suggestion.

Thanks

        Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic