[Live-devel] SRTP statistics

BENMOUSSA Yahia - Contractor yahia.benmoussa at external.thalesgroup.com
Sun Sep 29 01:02:41 PDT 2024


Classified as: {OPEN}

OK, I understand.
  
However, what could you suggest to inform  user-level code about SRTP authentication errors?

In fact, we need in our application to log “AUTHENTICATION FAILURE” events as “RECOMEDED” in section 3.3 of RFC 3711.

Yahia


{OPEN}

-----Message d'origine-----
De : live-devel <live-devel-bounces at us.live555.com> De la part de Ross Finlayson
Envoyé : vendredi 27 septembre 2024 17:02
À : LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Objet : Re: [Live-devel] SRTP statistics

No, I don’t want to make this change, because it would be a fairly large change to the code, with limited benefit.

In particular, “RTPReceptionStats” was intended primarily to be used as a database of statistics to be used when generating RTCP Reception Report (“RR”) packets that get transmitted back to the server.  If there is a specific RTCP Reception Report extension (defined by an IETF RFC) that includes these sort of statistics (e.g., number of SRTP authentication errors) that you wish to have implemented, then let me know, and I will consider supporting this.

Also:

>  The decrypted SRTP packets with authentication errors are not dropped. Instead, a counter is incremented which provides information to the user about the integrity of the received stream.  Then, it is up to user to consider or not the authentication issues.

I don’t agree with this at all.  If a SRTP packet fails an authentication check, then it is because either (1) there is a bug in the sender’s code (such as the one that you identified recently), or (2) a third party is injecting bogus packets into the stream, either to try to impersonate the sender, or more likely (because they won’t know the encryption keys) trying to do a 'denial-of-service' attack by sending junk data.  In this case it is correct for the receiver to be dropping these packets; the bogus decrypted data should definitely should not be passed up to user-level code.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel



More information about the live-devel mailing list