Hello Siddhartha ,
Thanks for the detailed answer .. I think you should be ready to receive and 
play back media(with all the codecs u have offered) as soon as you send the 
offer to avoid the so called clipping phenomenon especially when you are 
dealing with early media (announcement being played back from an audio server).
The SSRC exchange as you said , is still susceptable to MOM/replay attacks..
I think the real solution would be to use (as Dale said) use some kind of media 
level security like SRTP.
SRTP has a authentication tag which can be used to validate the other end , not 
sure how heavy weight it will be though and it wont solve the early media 
problem as SRTP will need a key exchange.
Regards ,
Sayan
P.S. SRTP has built in mechanism to prevent replays as well.


________________________________

From: Siddhardha Garige [mailto:[EMAIL PROTECTED]
Sent: Friday, May 26, 2006 10:56 AM
To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks); 
[email protected]
Subject: RE: [Sip-implementors] Query on when to open RTP ports during 
offer/answer


Sayan,

After sending an INVITE you need either a 200OK or 183 Session progress with 
SDP to open your RTP ports and start receiving media. With out a response how 
do you know if you are getting data from intended UA or not? I might be wrong 
but my understanding of ready to receive media is to keep the port open for 
media.

Regarding data coming from different IP Address, there is a section in RFC 3246 
that states that its application signalling protocols job to authenticate the 
UAs.

11 Security Considerations
   There are numerous attacks possible if an attacker can modify offers
   or answers in transit.  Generally, these include diversion of media
   streams (enabling eavesdropping), disabling of calls, and injection
   of unwanted media streams.  If a passive listener can construct fake
   offers, and inject those into an exchange, similar attacks are
   possible.  Even if an attacker can simply observe offers and answers,
   they can inject media streams into an existing conversation.
   Offer/answer relies on transport within an application signaling
   protocol, such as SIP.  It also relies on that protocol for security
   capabilities.  Because of the attacks described above, that protocol
   MUST provide a means for end-to-end authentication and integrity
   protection of offers and answers.  It SHOULD offer encryption of
   bodies to prevent eavesdropping.  However, media injection attacks
   can alternatively be resolved through authenticated media exchange,
   and therefore the encryption requirement is a SHOULD instead of a
   MUST.
   Replay attacks are also problematic.  An attacker can replay an old
   offer, perhaps one that had put media on hold, and thus disable media
   streams in a conversation.  Therefore, the application protocol MUST
   provide a secure way to sequence offers and answers, and to detect
   and reject old offers or answers.


Coming to recipient UA using different IP address and port to send media, I can 
suggest a solution but I dont know how good it is. It is up for a debate and i 
would be happy to see some one throwing some light on that.

RTP packets has a unique Sync Source ID in RTP header. If UAs can exchagne this 
sync source id in SDP body in INVITE and 200OK. Once the media session starts, 
decode RTP packets with matching Sync Source ID only  and drop other packets. 
you will know for sure you are decoding media only form the confirmed UA.

Hope this helps.

-Sid


[EMAIL PROTECTED] wrote:

        Hello Siddhardha/All ,
        The offer answer RFC says that you should be ready to receive media as 
soon as you send the offer.
        That is where my doubt comes in ...
        If I start receiving my media before any answer from the other side , 
how do I know for sure that it's actually the intended called party who is 
sending me the packets.
        Also ,after I receive the answer if the called party plays the media 
from a different IP address than the one he is using to receive media , how do 
I know that it's actually the called party who is playing me the media , I 
looked into SRTP , but that does not seem to have a solution for this ...
        Regards ,
        Sayan
        

________________________________

        From: Siddhardha Garige [mailto:[EMAIL PROTECTED]
        Sent: Thursday, May 25, 2006 8:17 PM
        To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks); 
[email protected]
        Subject: Re: [Sip-implementors] Query on when to open RTP ports during 
offer/answer


        Sayan,
        Dont you have to wait for a response 183 or 200 OK before you open your 
RTP ports?

        Siddhardah


        [EMAIL PROTECTED] wrote:



                Hello All ,
                Once I send an offer in in INVITE I am supposed to be ready to 
listen to
                media.
                However If I start getting media packets before getting the 
answer , I
                do not know for sure whether the called
                Party is playing me the media or somebody else is playing me 
the media.
                What do I do in this case ? Should I be rejecting the media 
packets till
                I get an answer ?
        
                Also if the called party plays the media from a different IP 
address
                from the one which he provides in the the SDP (for receiving 
media)how
                can I be sure it's not some kind of attack on my UA ?
                Regards ,
                Sayan
        
        
                The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments.
        
                WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email.
        
                www.wipro.com
        
                _______________________________________________
                Sip-implementors mailing list
                [email protected]
                
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        




        *******************************************************
        Siddhardha N. Garige
        Tampa, FL.
        Ph: (813)-298-4236.

        www.pbase.com/garige

        *******************************************************
________________________________

        Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great 
rates starting at 1ยข/min. 
<http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com>
 




*******************************************************
Siddhardha N. Garige
Tampa, FL.
Ph: (813)-298-4236.

www.pbase.com/garige

*******************************************************

________________________________

Feel free to call! Free PC-to-PC calls. Low rates on PC-to-Phone. Get Yahoo! 
Messenger with Voice 
<http://us.rd.yahoo.com/mail_us/taglines/postman10/*http://us.rd.yahoo.com/evt=39663/*http://messenger.yahoo.com>



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to