Subject: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 05:57:24 -0800

If a proxy hosts two domain one.example.com and two.example.com on the same
IP and port, this does not seem to work. The wrong TLS connection would be
used. The problem is the cache is populated with the IP/port as the index
instead of using the cert name as the index.

The Para 
   Because an alias connection might be reclaimed during a transaction,
   clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL
   and ACK (for non 2xx responses) to the same port.  If the alias
   connection no longer exists, the client SHOULD open a new connection
   to the resolved address and send the CANCEL or ACK there instead.
   The newly opened connection MAY be inserted into the alias table.

This scared me thought I can't put my finger on exactly why. It seems like
it open opportunities for DDOS with amplification. I don't remember all the
reasons that this text was in 3261 but I would to understood why this text
was in 3261 and that it was ok to remove. 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Mar 2006 13:59:31 -0600

Cullen Jennings wrote:
> If a proxy hosts two domain one.example.com and two.example.com on
> the same IP and port, this does not seem to work. The wrong TLS
> connection would be used. The problem is the cache is populated with
> the IP/port as the index instead of using the cert name as the index.

Cullen:

To make sure I understand you, this is what *I think* you are
talking about:

                        Virtual Proxy (VP)
       P1 ---------\           |
                    `--------- +--> one.example.com (VP1)
                    ,--------- +--> two.example.net (VP2)
       P2 ---------/           |

VP2 is able to use the existing alias to send requests to P1, an
alias which was originally established between P1 and VP1 (not
VP2).

Is the charcterization of your concern accurate?  If so,
there are various ways to combat this: (1) VP could be made to
maintain a separate alias table for all the virtual hosts it
supports; (2) as you suggest, somehow use the cert in the
indexing algorithm; (3) disable connection reuse for virtual
SIP hosting.

1 seems to be the most appropriate, given that the VP will need
to segregate the users belonging to each domain separately as
well as the certs and other related logistics.

I am curious: how many proxy servers today support virtual SIP
hosting?

> The Para Because an alias connection might be reclaimed during a
> transaction, clients SHOULD NOT enforce the RFC 3261 requirement of
> sending CANCEL and ACK (for non 2xx responses) to the same port.  If
> the alias connection no longer exists, the client SHOULD open a new
> connection to the resolved address and send the CANCEL or ACK there
> instead. The newly opened connection MAY be inserted into the alias
> table.
> 
> This scared me thought I can't put my finger on exactly why. It seems
> like it open opportunities for DDOS with amplification. I don't
> remember all the reasons that this text was in 3261 but I would to
> understood why this text was in 3261 and that it was ok to remove.

I think the paragraph you quote above is not worded quite
correctly.  All that is being said is something to capture the
following case:

    P1          P2
     ---------> INV succeeded and alias established
     ....
     <-------- re-INV over the existing alias;
               re-INV arrives successfully
     XXX       Connection closed at P1
      X<------ CANCEL goes out; dropped because connection
               closed at P1
     <-------- Open a new connection to the resolved address to
               send the CANCEL

This is the normal behavior in rfc3261; CANCELs and ACKs to non-2xx
go to the same destination, but if the connection has been
closed (for whatever reason), then the client will open a new
connection.

I will clarify this in the next revision.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 22:35:52 -0800

> I am curious: how many proxy servers today support virtual SIP

I know of several proxies today that will support multiple domains. However,
all the ones that I have seen that do TLS require a separate port for each
domain. That is because the TLS extensions to specify the domain in the
handshake are not that widely used yet.

In early versions of HTTP, you needed a port per domain on a web server.
This turned out to be undesirable in the long run and got fixed. I would
rather not repeat the mistake.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 22:35:52 -0800

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Mar 2006 08:26:12 -0600

> handshake are not that widely used yet.

True; for those who are using OpenSSL, there is a patch to OpenSSL
to support rfc3546.  Information for the patch is at:
http://www.mail-archive.com/[email-masked]/msg20260.html.
But I do not think it has made it into the last stable release for
OpenSSL (0.9.8).

- vijay
> handshake are not that widely used yet.

True; for those who are using OpenSSL, there is a patch to OpenSSL
to support rfc3546.  Information for the patch is at:
http://www.mail-archive.com/[email-masked]/msg20260.html.
But I do not think it has made it into the last stable release for
OpenSSL (0.9.8).

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Mar 2006 10:14:51 -0500

>> handshake are not that widely used yet.

In the long run this doesn't seem good enough.
I would like to have the option of having my home cable provider host my 
private domain for me. But that provider can't reasonably have a 
separate port for every domain it hosts.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 14 Mar 2006 19:06:39 +0100

Cullen,

> instead of using the cert name as the index.

At first I did not understand your point, until I saw your other posting on 
the -04 version: [copy]

| Second, I don't think it works. If a server runs two virtual domain a.com
| and b.com both on 1.2.3.4:5060 and use the TLS extended hello to separate
| them, then if it connects to C as A.com, and later C wants to send a sips
| message to B.com, it will deliver it over the connection to A.com which is
| totally broken from a security point of view.

So what you're saying is that a TLS connection should not be used to 
multiplex traffic for different virtual domains, even though it is known to 
end up at the exact same host and port?

If A.com really feels that way, I suppose the solution would be for it to 
not request an alias when it connects to C. But to be honest, since it can 
be verified that the connection to A.com arrives at the same host and port 
as B.com, I don't see why this would be "totally broken". Could you expand 
on that?

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 01:03:17 +0200

> separate port for every domain it hosts.

exactly.  this is one of the many examples where implementations for key
SIP specifications don't really exist today.  since security seems to
rely heavily on SIP/TLS, i would suggest retiring the working group
until decent SIP/TLS implementations exits and after that resume the
work.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 16:26:57 -0600

> until decent SIP/TLS implementations exits and after that resume the

nah, you're just applying the wrong model. What you need is a  
delegation from the private domain that says the cable provider is  
authoritative for it, then use the cable provider's credentials in  
the communication.

If we can eliminate the brokenness of retargeting proxies (thereby  
solving the unanticipated respondent problem), we're good to go.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 Mar 2006 11:21:12 -0800

> end up at the exact same host and port?

Yes exactly, the problem is when the message arrives on a connection that is
from both A.com and B.com, the proxy receiving it does not know if it came
from A.com or B.com and can't make the appropriate policy decisions on what
to do with based on which domain it came from. Proxy often implement white
or black list style authorization policy based on where a call came from.