Subject: [MMUSIC] Functionality missing in offer/answer

From: Roman Shpount <[email-masked]>
Date: 06 Feb 2002 02:14:04 GMT

Hi Folks,

From my point of view the following functionality is missing in offer/answer:

1. Ability to authorize media streams

SDP, due to its roots as a conference description protocol, does not specify any information about media stream origination address or any information that can be used to determine whether media was originated by a valid source. Since an end point or a firewall has no information to authorize media streams, deploying any offer/answer communication systems on public networks presents an unjustified security risk. Any party on the same network can scan a host for open UDP ports and send series of RTP packets that will interrupt all the RTP streams terminated by this host.

As far as I am aware current implementations are trying to avoid this problem by only accepting media from IP address specified as destination address for the media stream. This contradicts the current offer/answer draft and does not really solve the security problem, since origination IP address can be spoofed. The other solution is to store SDES and origination IP from the first media packets that pass probation and ignore all subsequent packets from the different IP or with different SDES. This solution is more secure, but contradicts current RTP specifications. 

Solution that I propose is to provide a way to specify SDES and/or origination IP in the offer/answer SDP. Unfortunately, this solution does not interoperate well with early media, since it will cause all the early media packets to be received but ignored.

2. Causing the other party of an already established session to send a new offer

This functionality is often needed when functionality similar to SIP REFER method is implemented using Back-to-Back SIP User Agent and re-INVITES. I believe this issue was brought up already during the discussion of the original offer/answer. Consider the following scenario:

1) a session is established through a Back-to-Back SIP User Agent between users A and B.

2) a Back-to-Back SIP User Agent needs to 

According to current specifications there is no reliable way to implement this scenario. If a new offer is received by a Back-to-Back SIP User Agent from C there is no way to ensure it will satisfy any of the requirements for the session description during session modification (not decreasing number of streams etc). On the other hand if the description of the session between A and B is used as offer to C it might be rejected due to the fact that media handling capabilities of A and C might not intersect (even though communications between C and B are possible). 

Additionally, knowledge of potential capabilities is insufficient to solve this problem, since the real offer (with valid destination ports and addresses) needs to be given to one of the parties and since this offer needs to compatible with the current session. 

The proposed solution to this problem is to cause one of the parties to send an offer that will be on one hand compatible with the current session, but on the other hand will include all the end point's desired media capabilities.  

___________________________________
Roman Shpount, VP of Technology
aTelo, Inc. 
2107 Wilson Blvd., Suite 301 
Arlington, VA 22201 
PCN: 703-621-4040 for voice / fax
www.atelo.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Feb 2002 21:24:32 -0500

inline.

Roman Shpount wrote:
> SDP, due to its roots as a conference description protocol, does not
> specify any information about media stream origination address or any
> information that can be used to determine whether media was originated
> by a valid source. Since an end point or a firewall has no information
> to authorize media streams, deploying any offer/answer communication
> systems on public networks presents an unjustified security risk. Any
> party on the same network can scan a host for open UDP ports and send
> series of RTP packets that will interrupt all the RTP streams terminated
> by this host.
> 
> As far as I am aware current implementations are trying to avoid this
> problem by only accepting media from IP address specified as destination
> address for the media stream. This contradicts the current offer/answer
> draft and does not really solve the security problem, since origination
> IP address can be spoofed. The other solution is to store SDES and
> origination IP from the first media packets that pass probation and
> ignore all subsequent packets from the different IP or with different
> SDES. This solution is more secure, but contradicts current RTP
> specifications.
> 
> Solution that I propose is to provide a way to specify SDES and/or
> origination IP in the offer/answer SDP. Unfortunately, this solution
> does not interoperate well with early media, since it will cause all the
> early media packets to be received but ignored.

That provides pretty much no security, since its totally spoofable.

The right way is to use SRTP. It will provide true cryptographic
authentication. You will be able to signal SRTP usage in SDP, and thus,
in offer/answer, and have proper security.

> This functionality is often needed when functionality similar to SIP
> REFER method is implemented using Back-to-Back SIP User Agent and
> re-INVITES. I believe this issue was brought up already during the
> discussion of the original offer/answer. Consider the following
> scenario:
> 
> According to current specifications there is no reliable way to
> implement this scenario. If a new offer is received by a Back-to-Back
> SIP User Agent from C there is no way to ensure it will satisfy any of
> the requirements for the session description during session modification
> (not decreasing number of streams etc). On the other hand if the
> description of the session between A and B is used as offer to C it
> might be rejected due to the fact that media handling capabilities of A
> and C might not intersect (even though communications between C and B
> are possible).
> 
> Additionally, knowledge of potential capabilities is insufficient to
> solve this problem, since the real offer (with valid destination ports
> and addresses) needs to be given to one of the parties and since this
> offer needs to compatible with the current session.
> 
> The proposed solution to this problem is to cause one of the parties to
> send an offer that will be on one hand compatible with the current
> session, but on the other hand will include all the end point's desired
> media capabilities.

This is covered thorougly in draft-ietf-sip-rfc2543bis-07. It has
nothing to do with offer answer. O/A doesn't tell you how or when you
send offers, only what the exchange needs to be when you do. O/A also
doesn't tell you how to formulate offers, only provides guidelines for
how you can. In bis-07, it explicilty mentions in Section 14.2, lines
2278 - 2285, which read:

A UAS providing an offer in a 2xx (because the INVITE did not contain an
offer) SHOULD construct the offer as if the UAS were making a brand new
call, subject to the constraints of sending an offer which 2279
updates an existing session, as described in [1] in the case of SDP.
Specifically, this means that it SHOULD 2280
include as many media formats and media types that the UA is willing to
support. The UAS MUST ensure 2281
that the session description overlaps with its previous session
description in media formats, transports, or 2282
other parameters that require support from the peer. This is to avoid
the need for the peer to reject the session 2283
description. If, however, it is unacceptable to the UAC, the UAC SHOULD
generate an answer with a valid 2284
session description, and then send a BYE to terminate the session. 2285

bis has always allowed one side to "prod" the other into making the
offer by sending an INVITE without SDP, and that text still exists in
bis-07.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com