--- Begin Message ---
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-boun...@us.live555.com> De la part de Ross Finlayson
Envoyé : vendredi 27 septembre 2024 17:02
À : LIVE555 Streaming Media - development & use <live-de...@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@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


--- End Message ---
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to