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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 13:18:07 -0500

> -----Original Message-----
> From: Shail Bhatnagar [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 12:38 PM
> To: James Undery
> Cc: Jonathan Rosenberg; [email-masked]'
> Subject: Re: [SIP] Issue with domain names in Via header
> 
> 
> James Undery wrote:
> > 
> > Shail Bhatnagar wrote:
> > 
> > > 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.
> > 
> > I guess you are talking about stateless proxies. This will 
> fail for stateless
> > proxies true.
> 
> 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.

The utility will depend on the failure mode, correct. 

Its also true that this is only useful for a stateful proxy.

It is also the case that if the failed proxy had forked, multiple responses
might be passed upstream to the UAC.

If the process on the target host dies, you will get ICMP port unreachable
errors.
If the host itself crashes, it depends. There are ways to be smart about
configuring up gated so that you get a destination net or host unreachable
as well. Hard to say what will happen with other failures.

A timeout can even be used for non-200 responses to INVITE; the proxy itself
will receive the ACK, and can treat lack of ACK as a failure.

-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: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Mar 2001 01:13:25 -0500

> From: Neil Deason [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 12:56 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> 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. 

The issue is already there. Since the received param is used to route the
response first, the attacker would need to spoof the source address of the
request. If they can spoof the source address of the request, they can set
it to the address of the target, and responses get sent to the target. This
attack exists in rfc2543. 

The solution is to only proxy authorized requests.

-Jonathan R.

---

> 
> Cheers,
> Neil.
> -- 
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
> 
> Jonathan Rosenberg wrote:
> > 
> > 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?
>

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Sat, 17 Mar 2001 16:23:22 -0600

>> From: Gonzalo Camarillo [mailto:[email-masked]]
>> 
>> However, stateless proxies will not catch ICMP messages, 
>
>Why not? Stateless proxies can still use connected UDP sockets; if a
>connected socket to the upstream host already existed (and had 
>been used)
>before the response is forwarded, the ICMP error will be 
>detected when the
>response is first transmitted; otherwise, ICMP error will be 
>detected when
>the retransmission of the response is forwarded.

This is certainly possible, but an odd design for a stateless
proxy. Ideally a stateless proxy would maintain zero resources
across transaction boundaries. In general, I would not expect
stateless proxies to catch ICMP errors.

>Igor Slepchin

/sean

---

From: "Neil Deason" <[email-masked]>
Date: Sun, 18 Mar 2001 21:38:00 -0000

>attack exists in rfc2543.

True but the proposed change would lower the bar for script kiddies. They wouldn't have to be capable of spoofing the source address just entering the victims address straight into the Via header.

Cheers,

Neil

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: Igor Slepchin <[email-masked]>
Date: Mon, 19 Mar 2001 11:15:27 -0500

Gonzalo,

I just didn't read the proposal carefully enough, what I was arguing for is
already in Jonathan's email:

"A proxy then checks the top-most Via header. If it contains a _domain name_
... the proxy SHOULD insert a "received" attribute into
that Via header, as described in Section 6.47.2."

---
Igor Slepchin

> > Jonathan's proposal requires that the hostname inserted in 
> the Via resolve
> > into the list of records that have the box that sent out 
> the request listed
> > with the higher priority than the others. If you have n 
> boxes in a cluster,
> > each of them would need to have a separate hostname that'd 
> resolve to a
> > differently prioritized list. If we made received param 
> mandatory, all of
> > the boxes in that cluster could share the same hostname.
> > 
> 
> 
> But what about the other direction (requests)? A stateless proxy MUST
> choose the same host within a trasaction (actually, I am proposing to
> add "SHOULD within a session"). Therefore it is necessary to 
> have n SRV
> records per cluster anyway.

Without received param, response failover would require having n hostnames
for a cluster of n proxies, each of the hostname resolving to n SRV RR
records. Requiring received parameter would allow operating with a single
hostname (representing the whole cluster) that would resolve to n SRV RR
records. Only the latter is needed for requests.

---

From: "Neil Deason" <[email-masked]>
Date: Mon, 19 Mar 2001 22:03:43 -0000

> > >Yours is solved by ordering the servers in a certain order
> >
> > >(alphabetical, for instance) before applying the process to choose
> > one.
> >
> > I don't see how this can be guaranteed to help. If the list of servers
> > you get back has changed alphabetically the modulo N hash of the
> > Call-ID can still pick the wrong server.
>
>You get back the names from DNS, you order them, and then apply the
>modelo N hash.

Yes I know that is what the spec says. Let try to me
give you an example of why I think it can fail
to guarantee you pick the same server everytime.

Say the 1st time a stateless proxy does a DNS lookup
it gets the following SRV RRs:

_sip._udp.example.com. SRV   10 1 8080 host1.example.com.
_sip._udp.example.com. SRV   10 1 8080 host2.example.com.
_sip._udp.example.com. SRV   10 1 8080 host3.example.com.

All the servers have the same priority and have been sorted
alphabetically. Say the hash of the Call-ID is 23. The modulo
N (N = 3) of a hash of the Call-ID gives a value of 2. The
selected server is therefore host2.example.com as per the
algorithm defined in RFC 2782.

Later the stateless proxy queries DNS again for
a retransmission or even by your proposal a
later request in a session. This time it gets back:

_sip._udp.example.com. SRV   10 1 8080 host1.example.com.
_sip._udp.example.com. SRV   10 1 8080 host2.example.com.
_sip._udp.example.com. SRV   10 1 8080 host3.example.com.
_sip._udp.example.com. SRV   10 1 8080 host4.example.com.

The modulo N (now N = 4) of the hash of the same Call-ID
gives a value of 3, so this time the selected server will
be host3.example.com

Cheers,
Neil.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2001 01:54:55 -0500

> From: Igor Slepchin [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 11:15 AM
> To: 'Gonzalo Camarillo'; Igor Slepchin
> Cc: 'Neil Deason'; Henning Schulzrinne; Arnoud van Wijk 
> (ELN); Jonathan
> Rosenberg; [email-masked]'
> Subject: RE: [SIP] Issue with domain names in Via header
> 
> 
> Gonzalo,
> 

Right. I wanted to make sure we could route responses in the normal case
without DNS processing. This also helps deal with the n-way SRV case.

Whether or not a "stateless" proxy can actually use this depends on your
definition of state. As Igor has pointed out, a truly stateless proxy
doesn't exist. Its possibly to build proxies that don't have state that
increases per transaction, but only per connection; these proxies can only
be built where the connected UDP sockets are not established per
transaction. There are certainly cases where this can happen, although its
more limited. In any case, its an implementation issue.

-Jonathan R.

---