Subject: RE: [SIP] meaning of IP address in SDP

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 May 2001 14:10:44 -0700

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:[email-masked]]
> Sent: Friday, April 27, 2001 1:46 PM
> To: [email-masked]'
> 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
> [email-masked]                     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
> [email-masked] 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 
[email-masked] with "subscribe" in the body.

---

From: "Gross, Gerhard" <[email-masked]>
Date: Tue, 1 May 2001 16:35:06 -0700

AAA/Policy management also likes to have session 5-tuple
information on which to make a policy based admission
and AAA decisions. Ideally, this information would
be relayed to the SIP proxy in SIP messages, then
forwarded via other protocols to AAA/policy servers.
AAA/policy actions would be taken before media
was sent.

Gery

> From: Romel Khan [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 4:16 PM
> To: 'Christian Huitema'; Jonathan Rosenberg
> Cc: [email-masked]
> 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
> 
> 
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 5:11 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: RE: [SIP] meaning of IP address in SDP
> 
> 
> Jonathan,
>

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 2 May 2001 09:34:53 -0700

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

> From: Medhavi [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 7:00 PM
> 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" <[email-masked]>
> To: "Ranjit Avasarala" <[email-masked]>; "Romel Khan"
> <[email-masked]>; "'Christian Huitema'"
> <[email-masked]>; "Jonathan Rosenberg"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, May 02, 2001 12:47 AM
> Subject: Re: [SIP] meaning of IP address in SDP
> 
> 
> >
> > ----- Original Message -----
> > From: "Ranjit Avasarala" <[email-masked]>
> > To: "Romel Khan" <[email-masked]>; "'Christian Huitema'"
> > <[email-masked]>; "Jonathan Rosenberg"
> > <[email-masked]>
> > Cc: <[email-masked]>
> > 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 <[email-masked]>
> > > To: 'Christian Huitema' <[email-masked]>; Jonathan
> > Rosenberg
> > > <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Tuesday, May 01, 2001 6:15 PM
> > > Service providers may have a need to be able to send RTP streams
to a
> port
address
> and
> > UDP
security
> is
> > > definitely an issue (i.e. if no encryption method such as TLS/SSL
has
> been
> 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
> > > So shouldn't SDP RFC be enhanced to be able to include the sending
> port
> in
> > > 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
> > > > won't be the address in the c line, several implementations
appear
> to
> > > > Please, in your implementations, do not make any assumptions
about

---

From: Tim Rang <[email-masked]>
Date: Wed, 2 May 2001 12:40:22 -0400

This would only change the nature of the clipping.  Rather than a firewall
dropping packets on the floor, your going to have a callee talking into the
phone with no RTP packets being produced.  From the perspective of the
caller, the problem has actually gotten worse by waiting for the ACK because
there is extra roundtrip time.

Tim Rang

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 2 May 2001 09:52:30 -0700

I should have written, "no RTP packet until a three ways handshake has
been completed." The manyfolks draft uses a combination of PRACK and
COMET to achieve this result.

> From: Tim Rang [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 9:40 AM
> To: 'Christian Huitema'; Medhavi
> dropping packets on the floor, your going to have a callee talking
into

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 3 May 2001 00:33:59 -0700

HI Adam

Yes, I imagine there might be a few implementations doing this but how many
use a completely different IP address?

I imagine that most implementations currently ignore the source port.
However this "four tuple" is still a lot better for opening holes in
firewalls than nothing at all (of course full symmetric RTP is the more
preferable).

Alternatively, what about adding a SIP option requesting the UA's use
symmetric RTP? Require: symmetric-media ? If symmetric media is required to
cross a NAT or firewall then the proxy/UA should be able to request this
from the UA's in order for the call to be _successfully_ established.
[Otherwise you will get that annoying situation where the UA says the call
is connected but you can't hear the other person.]

Robert.

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	Thursday, May 03, 2001 12:17 AM
To:	'Fairlie-Cuninghame, Robert'; 'Christian Huitema'; Medhavi
Cc:	[email-masked]
Subject:	RE: [SIP] meaning of IP address in SDP

-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
...
>How many people are not using symmetric RTP currently (ie, not sending from
same source >IP/port as you receive).

I'm not. It's easier for my application to have separate sending
and receiving threads, each managing its own socket.

I'll bet there are other implementations doing the same thing.

/a

---

From: "Gross, Gerhard" <[email-masked]>
Date: Thu, 3 May 2001 09:13:56 -0700

This solution would also allow policy management
on a more stringent level (5-tuple instead of
3-tuple) - a desireable feature.
 
Gery

HI Adam 

Robert. 

BM__MailData-----Original Message----- 
From:   [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Thursday, May 03, 2001 12:17 AM 
To:     'Fairlie-Cuninghame, Robert'; 'Christian Huitema'; Medhavi 
Cc:     [email-masked] 
Subject:        RE: [SIP] meaning of IP address in SDP 

-----Original Message----- 
>From: Fairlie-Cuninghame, Robert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
... 

/a