Subject: [SIP] Issue with domain names in Via header

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2001 17:25:25 -0500

Folks,

There is an issue with via processing that prevents a useful feature from
being applied.

The problem is the following. Proxy P1 inserts a via with a domain name,
proxy1.foo.com, and forwards it to proxy 2. Proxy 2 checks the via, and
since it doesn't match the source IP address where the request came from
(they are not equal), inserts a received parameter with that IP address,
1.2.3.4. It forwards the request. When its time to send a response, P2 looks
at the Via, sees there is a received param, and uses the IP address present
there to forward the response. 

As a result of this, insertion of domain names in Via accomplishes nothing.
Ideally, I'd like to be able to insert a domain name which resolves to an
SRV record; that record having, in the example above, the highest priority
for 1.2.3.4, and lower priorities for backups. The result of this is that a
proxy could fail mid-transaction, and another can step in to take its place
to forward the response. Right now, this capability won't work.

To fix it, is simple. I would suggest modifying the text in 6.47.1, which
currently reads:

>A proxy SHOULD check the top-most Via header field to ensure that it
contains the sender's 
>correct network address, as seen from that proxy. If the sender's address
is incorrect, the 
>proxy MUST add an additional "received" attribute, as described in Section
6.47.2.

to:

A proxy then checks the top-most Via header. If it contains a domain name,
or it contains an IP address which is not equal to the one in the source IP
address of the request, the proxy SHOULD insert a "received" attribute into
that Via header, as described in Section 6.47.2.

Then, modify the rules in section 6.47.5, so that the third bullet, which
currently reads:

>Otherwise, if it is a receiver-tagged field (Section 6.47.2), send the
response to the 
>address in the "received" parameter, using the port indicated in the
"sent-by" value, or 
>using port 5060 if none is specified explicitly.

instead reads:

Otherwise, if it is a receiver-tagged field (Section 6.47.2), send the
response to the
address in the "received" parameter, using the port indicated in the
"sent-by" value, or 
using port 5060 if none is specified explicitly. If the sending the response
results in 
failure (such as an ICMP port unreachable), send the response to address in
the "sent-by" 
field.

The result of this change is that we send the response to the place the
request came from under normal conditions, but under failures, it can be
routed to a backup. This change is backwards compatible, and will result in
a nice feature, which is the reason usage of domain names was recommended in
the first place.

Comments?

-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: (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.

---

From: Henry Chen <[email-masked]>
Date: Thu, 15 Mar 2001 11:04:10 -0600

Hi Jonathan:

    Does the changes help for the transaction statefull proxy failure scenario
    (consider the forking proxy also)?

    Thanks,

    Henry

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 15 Mar 2001 12:18:16 -0500

I am not sure how this is going to work.
If the node with the IP addr in "received"
parameter is dead, there is no way you will
get an ICMP unreachable, nor will UDP send() fail.
Secondly, even if the node is up but server 
is down for maintenance or something, one 
UDP send() will not give you the ICMP unreachable.
You have to atleast do 2 UDP send() to get a -1
with errno set. 
Shail

---

From: James Undery <[email-masked]>
Date: Thu, 15 Mar 2001 17:29:01 +0000

> get an ICMP unreachable, nor will UDP send() fail.

I guess you are talking about stateless proxies. This will fail for stateless
proxies true.

> You have to atleast do 2 UDP send() to get a -1

This is not a problem.

James

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 15 Mar 2001 12:38:14 -0500

> I guess you are talking about stateless proxies. This will fail for stateless

No, I am not talking about state here. Try to do
a UDP send() to an IP addr that does not exist.
send() is not going to fail. The only time this
is useful is when the IP addr in question is good
but nobody is listening on that port. The second
send() will then return -1 with errno set.

(Needless to say you can do a send() only after
doing connect())

> > You have to atleast do 2 UDP send() to get a -1

Why  is this not a problem ? There is nothing
in the spec which says that proxy will retransmit
a message like 183 or 200 or am I missing something ?

---

From: Neil Deason <[email-masked]>
Date: Thu, 15 Mar 2001 17:56:00 +0000

It might be worth considering that this does raise a security 
issue. Malicious users could use the mechanism to manipulate 
a server into sending responses to inappropriate destinations. 

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net