Subject: [Sip] SDES & Media Relay

From: Fatih Eyüp NAR <[email-masked]>
Date: Thu, 25 Jan 2007 04:57:45 -0800 (PST)

Hi;
I am little bit confused with following expression within RFC 4568 Section 7.1.4:
"Another consideration here applies to media relays; if the relay changes the media endpoint on one side transparently to the other side, the relay cannot operate as a simple packet reflector but will have to actively engage in SRTP packet processing and transformation (i.e., decryption and re-encryption, etc.)."

Media Relay is simple , straight forward -dummy we may say- network element whose duty is to transparently pass received media packets from one port to another . 

I couldn't catch the purpose of "actively engage in SRTP packet processing and transformation (i.e., decryption and re-encryption, etc.)" for Media Relay.

Thanks from Now

fatih e.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Jan 2007 09:36:25 -0800

If you're doing sdescriptions (RFC4568) and have a media relay, you'll have
a situation like this, where Alice will be using key AAAA to Bob, and Bob
will be using key BBBB to Alice:

   Alice ------ [media relay] ------ Bob

If the media relay, unbeknownst to Alice, switches the media to Carol, like
this:

   Alice ------ [media relay]
                             \
                              \
                               \
                              Carol

the media relay can tell Carol Alice's key (AAAA) in the Invite, but there
is no way for the media relay to dictate or indicate to Carol that she
should transmit SRTP packets using Bob's old key (BBBB).  Instead, Carol
will choose her own key (let's call it CCCC).  But Alice can't decrypt SRTP
media encrypted with CCCC, because Alice doesn't know it.  The only way to
get this to work is:

  1. the media relay needs to tell Alice that the call has been 
     switched from Bob to Carol.
  2. the media relay needs to decrypt Carol's media traffic (using 
     key CCCC) and re-encrypt it with Bob's old key (BBBB).

The text in the RFC talks about (2).  

If you want to avoid having the media relay doing SRTP decrypt/encrypt
operations, you need to do (1), which means that Alice will know when the
call is switched from Bob to Carol.

-d

> -----Original Message-----
> From: Fatih Eyüp NAR [mailto:[email-masked]] 
> Sent: Thursday, January 25, 2007 4:58 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: SDES & Media Relay
> 
> Hi;
> "Another consideration here applies to media relays; if the 
> relay changes the media endpoint on one side transparently to 
> the other side, the relay cannot operate as a simple packet 
> reflector but will have to actively engage in SRTP packet 
> processing and transformation (i.e., decryption and 
> re-encryption, etc.)."
> 
> Media Relay is simple , straight forward -dummy we may say- 
> network element whose duty is to transparently pass received 
> media packets from one port to another . 
> 
> I couldn't catch the purpose of "actively engage in SRTP 
> packet processing and transformation (i.e., decryption and 
> re-encryption, etc.)" for Media Relay.
> 
> Thanks from Now
> 
> fatih e.

---

From: David R Oran <[email-masked]>
Date: Fri, 26 Jan 2007 12:55:07 -0500

> call is switched from Bob to Carol.
Right, scheme (1) as stated would violate the Monica property.
However, what stops the media relay from just doing a re-invite to  
Alice to force a re-key. Alice will know SOMETHING happened but no  
whether it was a transfer, and certainly not to whom.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Jan 2007 11:20:41 -0800

> whether it was a transfer, and certainly not to whom.

Sure, that would work, if that level of information leakage to
Alice is acceptable.  I agree that it's acceptable in all but
the most severe environments.

-d