Discuss why SEQ is signaled in the SDP

[kyzer-davis]

Current text has no mention of why SEQ is sent...

Need to discuss the SEQ value can be used to help move the sliding window in scenarios where the ROC the other side through they were going to use "moves backwards"

e.g Given UAC > RTP > B2BUA > SRTP > UAS_A

• UAC and UAS_A on a session via B2BUA, ROC 0
• Here B2BUA is inline encrypt of RTP to SRTP with signaling abstraction. That is, signaling from UAS_A is abstracted from UAC.
  • SSRC is retained from UAC through to UAS_A only payload is encrypted when passing through the B2BUA
• UAS_A places session on hold and B2BUA context is transferred to UAS_B (some music on hold streaming device).
  • Here UAC is never told to stop streaming media to B2BUA due to signaling abstraction
• While on hold UAC's sequence rolls over since it was never told to stop streaming due to signaling abstraction.
• The session is taken off hold and session resumed with UAS_A where UAS_A resumes IP:Port for media.
  • Since the TX SSRC remains along with the destination IP and Port the B2BUA may resume the original cryptographic context.
  • See RFC3711 Section 3.2.3. Mapping SRTP Packets to Cryptographic Contexts

Thus the problem:

• What ROC will B2BUA use to encrypt and what ROC will UAS_A use to decrypt?
  • Assume B2BUA, in finding the tuple and resuming the original cryptographic context between itself and UAS_A, reuses ROC 0:
    • Things may work since this is the last known ROC by UAS_A but the seq could be much lower than expected leading to sliding window/anti-replay issues (see second bullet).
  • Perhaps the B2BUA incremented the ROC to 1 in the context since it saw a rollover on the peer leg:
    • Without explicit signaling UAS_A would never know the encryptor was using ROC of 1 while they are using ROC of 0 (their last known ROC value)
    • Sure UAS_A could try ROC-1/ROC+1 logics but this does not scale nicely past a single rollover and many do not do this mid-session.
  • Either can be achieved by putting the ROC on the wire in SDP as ROC=0x0 or ROC=0x1 to explicitly signal the value of the encrypted packets post hold
  • What SEQ does UAS_A use for its sliding window post hold?
  • As described above, with ROC=0x0, the SEQ of a packet received by UAS_A could be less than what it original saw (meaning a packet would drop in the sliding window anti-replay check)
  • By sending SEQ=0x1234 in SDP from B2BUA to UAS_A, the implementation could reset the sliding window to allow for starting at that packet vs dropping it as a replayed packet.

[valvo27]

This is a common scenario in WxC and Webex App interops with LGW. The final fix for this has been tricky because of course we are missing the exchange of ROC value.

What I have been noticing is that our App doesn't care of the sequence number once the call is resumed, but the phones do care about it, so we have difference in implementation of the sliding windows.

To tackle this I would think adding the sequence would be idea, but that also expands the scope of the behavior expected from UAC and UAS from just the ROC value. My question would be should we cover the behavior of those here in this RFC to know how to react to such SEQ values? It may also need a mention about the sliding window and how it works once this is added.