Subject: RE: [SIP] Request/Responses from other addresses

From: "McMurry, Kathleen" <[email-masked]>
Date: Mon, 05 Jun 2000 21:35:06 +0000

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, June 05, 2000 4:26 PM
To: Sean Olson
Cc: [email-masked]; McMurry, Kathleen
Subject: Re: [SIP] Request/Responses from other addresses

Sean Olson wrote:
> > 
> > > What is the proper behavior of a Proxy in the following scenarios:
> > >
> > > Scenario1:
> > >
> > > OUA-----INVITE----->PS------INVITE----->TUA
> > > OUA2-----CANCEL---->PS
> > >
> > > In other words - the CANCEL comes from a different address than the
original
> > > INVITE came from.  The same question applies to a "retransmitted"
INVITE
> > > request prior to the final response.
> > >
> > >
> > > Scenario2:
> > >
> > > OUA---INVITE---->PS-----INVITE---->TUA
> > > TUA2--->200--->PS
> > >
> > > In other words - the final response (or any provisional response)
comes from
> > > a different address than the one that the INVITE was sent to.
> > >
> > > I know that AFTER the final response, any request can legitimately
come from
> > > a different source than the original request, but what is the proper
> > > behavior when this situation occurs PRIOR to the final response?
> > >
> > >
> > > Thanks,
> > > Kathleen McMurry
> > 
> > By different address you mean different source IP address, I'm
assuming(?)
> > (A different From: of course would not cause a problem -- the proxy
could return a 481)
> > 
> > I see no reason to state absolutely that the CANCEL or final response
MUST come from
> > the same IP address. There are obvious applications for exactly this
scenario.
>
> For security purposes, actually, you really do need to check that the
> CANCEL came from the same place as the request being cancelled (see the
> minutes of the security task force on this). CANCELs cannot usefully be
> authenticated directly, since they may come from proxies. That aside,
> CANCEL can come from anywhere.
>
> As for responses, I'm really not sure. The spec says nothing about this,
> as we had not considered it. It clearly requires some out-of-band
> communications between the entity which received the request, and the
> one which sent the response. I'm not sure what the application of that
> would be. That aside, there may be problems. For requests sent over TCP,
> the response is supposed to go over the same connection. Clearly it
> cannot if the response is generated somewhere else. I suspect some
> proxies may be upset if the connection to the server is open, and the
> response comes on a different connection, opened just to send the
> response. In the case of UDP, this will probably work, but you never
> know. 

Wouldn't you have the same security concerns with the response, since it
would allow an entity to redirect a call that was not sent to it?

-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.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Jun 2000 18:10:33 -0400

> would allow an entity to redirect a call that was not sent to it?

Yes, actually. Like CANCEL, a redirect response can be generated by a
proxy and also by a user agent. So, doing source address checks there is
probably a good idea. 

-Jonathan R.