RE: [SIP] meaning of IP address in SDP
"Christian Huitema" <huitema@exchange.microsoft.com> Wed, 02 May 2001 16:35 UTC
Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16544 for <sip-archive@odin.ietf.org>; Wed, 2 May 2001 12:35:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49BBB44365; Wed, 2 May 2001 12:35:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lists.bell-labs.com (Postfix) with ESMTP id 7B72544336 for <sip@lists.bell-labs.com>; Wed, 2 May 2001 12:34:59 -0400 (EDT)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Wed, 2 May 2001 09:35:44 -0700
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 09:34:54 -0700 (Pacific Daylight Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 May 2001 09:34:54 -0700
content-class: urn:content-classes:message
Subject: RE: [SIP] meaning of IP address in SDP
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4703.0
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFADB1C@speak.dogfood>
Thread-Topic: [SIP] meaning of IP address in SDP
Thread-Index: AcDTD+1vI3zqoyg5S/eN3JBF39BoQAAENjgA
From: Christian Huitema <huitema@exchange.microsoft.com>
To: Medhavi <mbhatia@nextone.com>
Cc: sip@lists.bell-labs.com
X-OriginalArrivalTime: 02 May 2001 16:34:54.0399 (UTC) FILETIME=[D13BECF0:01C0D325]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 02 May 2001 09:34:53 -0700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16544
One of the most interesting outcome of this discussion should be a memo describing the requirements to the MIDCOM protocol, and then a reverse memo describing the requirement imposed by midcom to SIP. As it stands today, we have the following: 1) Conventional firewall logic is that you want to open a pin-hole, not a truck-sized gap. This means that a five-tuple hole is preferred (protocol type, two address and port pairs) over a three-tuple (internal address+port pair, protocol type). 2) Our current specification of early media only works if the client can receive media immediately after sending an INVITE, which requires opening a three-tuple hole. 3) The five-tuple can only be known by the caller after receiving the 200-OK. This creates a race condition between the signaling message and the first RTP packets sent by the callee; should the 200-OK loose the race, the early RTP packets will bang against a closed firewall and be clipped. 4) The only way to guarantee that we don't have clipping of the initial packets is to require that no RTP packet be sent until the initial ACK is received. This is a problem similar to the "resource reservation" issue studied in the manyfolks draft. Since we want to enable media immediately after the call acceptation, this means that we have some kind of two-phase set-up: first set up a path with an initial three ways handshake, and then re-invite and start ringing. Doing that is not compatible with existing implementations, and would require a serious revisiting of the gatewaying between POTS and SIP. 5) Even if we implemented the two-phase handshake, the early-media problem would remain. There is a common telephony practice of sending recorded announcements during call set-up; the source IP address of these announcements is not likely to be the same as the source IP address used after call set-up is complete. It is theoretically possible to use the equivalent of call transfer to switch between multiple source in a controlled fashion, but this introduce a lot of signaling complexity. 6) The source IP address should be allowed to change during a call, e.g. if we want calls to outlive network renumbering. SIP supports that through the re-invite mechanism, but enforcing a five-tuple control introduces either a gap in the call or a race condition between RTP packets with the new source address and the re-INVITE. 7) Even if we changed the call flows, there are doubts that we can actually specify the five tuple, at least for the incoming packets: the source IP address may be unpredictable in the case of multi-homed hosts; the source port may be systematically different from the receive port in some implementation, e.g. parallel processing of the send and receive channels by different software or hardware components. 8) Many implementations already support exchange of RTP level authentication and encryption keys during the SIP call set-up. This provides a level of security that is at least as good as any control of the source address and port: if attackers can manage to read the signaling exchange and get the keys, they can just as well discover the IP addresses and ports, and send forged packets. So, can we convince midcom that we actually need to open holes that are a tiny bit larger than the initial pin-hole? Maybe something like a three-tuple hole on the receive side, and either a three-tuple or a five-tuple on the sending side? -- Christian Huitema > -----Original Message----- > From: Medhavi [mailto:mbhatia@nextone.com] > Sent: Tuesday, May 01, 2001 7:00 PM > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] meaning of IP address in SDP > > I dont think that source port/IP address checks provide > any security in this matter. The real security would be using > encryption which may be expensive and hard to get right. > > If a hacker wants to break down a call, or interfere with it, > changing the source address/port of the packets which he sends > to that of the actual source is probably the easiest thing to do. > So if the receiver is concerned about security, he must take other > measures as well, in addition to source check. Once we have them in place, > maybe the source check wont be that necessary, and may in fact become > a problem for protocol design later. > > > > ----- Original Message ----- > From: "Bob Penfield" <bpenfield@acmepacket.com> > To: "Ranjit Avasarala" <ranjitka@email.masconit.com>; "Romel Khan" > <rkhan@net2phone.com>; "'Christian Huitema'" > <huitema@exchange.microsoft.com>; "Jonathan Rosenberg" > <jdrosen@dynamicsoft.com> > Cc: <sip@lists.bell-labs.com> > Sent: Wednesday, May 02, 2001 12:47 AM > Subject: Re: [SIP] meaning of IP address in SDP > > > > > > ----- Original Message ----- > > From: "Ranjit Avasarala" <ranjitka@email.masconit.com> > > To: "Romel Khan" <rkhan@net2phone.com>; "'Christian Huitema'" > > <huitema@exchange.microsoft.com>; "Jonathan Rosenberg" > > <jdrosen@dynamicsoft.com> > > Cc: <sip@lists.bell-labs.com> > > Sent: Tuesday, May 01, 2001 7:38 PM > > Subject: Re: [SIP] meaning of IP address in SDP > > > > > > > Hi > > > But why should the receiver know about sender's sending port? Like > if > > > you go back to socket programming, the server only > > > needs to know client's receiving port for sending data. it does not > bother > > > about client's sending port. So I feel there is no need > > > to include sender's port number in the data. > > > > The receiver (UAS) does not need to know the sender's sending port, but > a > > SIP proxy or ALG in the signalling path that needs to tell a middlebox > (e.g. > > NAT or Firewall) to let the RTP flow thru needs the sender's sending > port, > > otherwise it has to say let all packets from any IP Address and port > thru > to > > the sender's (UAC's) receiving port. That would be a very bad thing from > a > > security point of view. > > > > Bob > > d:-) > > > > > > > > Any comments?? > > > > > > Regards > > > Ranjit > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: Romel Khan <rkhan@net2phone.com> > > > To: 'Christian Huitema' <huitema@exchange.microsoft.com>; Jonathan > > Rosenberg > > > <jdrosen@dynamicsoft.com> > > > Cc: <sip@lists.bell-labs.com> > > > Sent: Tuesday, May 01, 2001 6:15 PM > > > Subject: RE: [SIP] meaning of IP address in SDP > > > > > > > > > Service providers may have a need to be able to send RTP streams to a > port > > > and receive RTP streams from a different port (different IP address > and > > UDP > > > port). Jonathan Rosenberg's point would solve that need. But security > is > > > definitely an issue (i.e. if no encryption method such as TLS/SSL has > been > > > decided between sender & receiver). After an entity sends its > receiving > > port > > > through SDP and does not care who sends data to that receiving port is > > most > > > probably not going to be an acceptable solution to many providers who > may > > > not wish to use encryption either. > > > So shouldn't SDP RFC be enhanced to be able to include the sending > port > in > > > case different from the receiving port? > > > > > > Thanks. > > > > > > Romel Khan > > > Ph: (732)-363-0213, x241 > > > > > > > > > -----Original Message----- > > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > > Sent: Tuesday, May 01, 2001 5:11 PM > > > To: Jonathan Rosenberg > > > Cc: sip@lists.bell-labs.com > > > Subject: RE: [SIP] meaning of IP address in SDP > > > > > > > > > Jonathan, > > > > > > The point were this is likely to be tested is firewall traversal. For > > > security reasons, we are tempted to open a pinhole that specifies a > > > "five tuple" -- source and destination IP address and port, protocol > > > type. This requires being able to predict the source address used by > the > > > other end. According to your rule, we would not be able to do that. > This > > > seems reason enough to reconsider. > > > > > > By the way, the technical argument that you give is weak. It is > possible > > > to bind a socket to an address, which makes address selection possible > > > even on multi-homed machines. > > > > > > -- Christian Huitema > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Friday, April 27, 2001 1:46 PM > > > > To: 'sip@lists.bell-labs.com' > > > > Subject: [SIP] meaning of IP address in SDP > > > > > > > > Folks, > > > > > > > > There appears to be some continuing confusion about the > interpretation > > > of > > > > the IP address in the SDP of an INVITE or 200 OK. > > > > > > > > When user A sends an INVITE with SDP, and the stream is sendrecv > > > (which is > > > > the default), the IP address in the c line for that stream is the > > > address > > > > where A expects to receive media for that stream. It DOES NOT imply > > > that > > > > the > > > > source address of media that A sends will be equal to that IP > address. > > > The > > > > source IP address is chosen by the underlying OS based on its > routing > > > > tables. As such, a multihomed host has no way to know what the > source > > > > address of its RTP packets will be, until it actually tries to send > > > them. > > > > So, clearly, the IP address in the c line in the INVITE cannot > > > possibly be > > > > the source address, since A doesn't even know yet where it will send > > > > packets. > > > > > > > > Unfortunately, since rfc2543 does not explicitly say that the source > > > > address > > > > won't be the address in the c line, several implementations appear > to > > > have > > > > assumed that it will be. I want to make sure we are clear that this > > > > assumption is false. > > > > > > > > Please, in your implementations, do not make any assumptions about > the > > > > source address of media. > > > > > > > > Thanks, > > > > Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementor's list is the place to discuss implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to > > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the > body. > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
- Re: [SIP] meaning of IP address in SDP Ranjit Avasarala
- RE: [SIP] meaning of IP address in SDP Fairlie-Cuninghame, Robert
- RE: [SIP] meaning of IP address in SDP Romel Khan
- RE: [SIP] meaning of IP address in SDP Christian Huitema
- RE: [SIP] meaning of IP address in SDP Gross, Gerhard
- RE: [SIP] meaning of IP address in SDP Christian Huitema
- RE: [SIP] meaning of IP address in SDP Fairlie-Cuninghame, Robert
- RE: [SIP] meaning of IP address in SDP Tim Rang
- Re: [SIP] meaning of IP address in SDP Bob Penfield
- [SIP] meaning of IP address in SDP Jonathan Rosenberg
- RE: [SIP] meaning of IP address in SDP Christian Huitema
- RE: [SIP] meaning of IP address in SDP Gross, Gerhard
- RE: [SIP] meaning of IP address in SDP adam.roach