RE: [SIP] meaning of IP address in SDP

["Fairlie-Cuninghame, Robert" <[e-mail]>]

Hi Christian,

Good points.

I would rephrase (2) to say that early media (in this scenario) does not
work unless the UAC assumes symmetric RTP and the UAS provide an SDP in the
provisional response. That is, unless the UAS provides an SDP body in the
18x response and the UAC builds a {five-tuple} from it. This was discussed a
little last month on the list. 

I really wonder (ie, reality check):
a)	How many people are not using symmetric RTP currently (ie, not
sending from same source IP/port as you receive).
b)	How many current (non-sandpit) SIP products really allow RTP media
to come from _any_ IP address and port.  
c)	If any one can come up with non-neurotic reasons why it is necessary
to send from a different IP address than you send from.[Realistically!] If
so, I still believe there are other ways around this specialist scenario.

Regards,

Robert.

-----Original Message-----
From:	Christian Huitema [mailto:[e-mail]]
Sent:	Wednesday, May 02, 2001 5:35 PM
To:	Medhavi
Cc:	[e-mail]
Subject:	RE: [SIP] meaning of IP address in SDP

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:[e-mail]]
> Sent: Tuesday, May 01, 2001 7:00 PM
> Cc: [e-mail]
> 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" <[e-mail]>
> To: "Ranjit Avasarala" <[e-mail]>; "Romel Khan"
> <[e-mail]>; "'Christian Huitema'"
> <[e-mail]>; "Jonathan Rosenberg"
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, May 02, 2001 12:47 AM
> Subject: Re: [SIP] meaning of IP address in SDP
> 
> 
> >
> > ----- Original Message -----
> > From: "Ranjit Avasarala" <[e-mail]>
> > To: "Romel Khan" <[e-mail]>; "'Christian Huitema'"
> > <[e-mail]>; "Jonathan Rosenberg"
> > <[e-mail]>
> > Cc: <[e-mail]>
> > 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 <[e-mail]>
> > > To: 'Christian Huitema' <[e-mail]>; Jonathan
> > Rosenberg
> > > <[e-mail]>
> > > Cc: <[e-mail]>
> > > 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:[e-mail]]
> > > Sent: Tuesday, May 01, 2001 5:11 PM
> > > To: Jonathan Rosenberg
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > > > Sent: Friday, April 27, 2001 1:46 PM
> > > > To: '[e-mail]'
> > > > 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
> > > > [e-mail]                     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
> > > > [e-mail] 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
> > > [e-mail] 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
> > > [e-mail] 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
> > > [e-mail] 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
> > [e-mail] 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
> [e-mail] 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 
[e-mail] with "subscribe" in the body.