Subject: Re: [Sip] target topology in connect-reuse

From: Cullen Jennings <[email-masked]>
Date: Sat, 11 Dec 2004 12:52:33 -0800

I think the basic idea you are getting at here is right but not sure the TLS
part at the end is the right way to go. We might be saying the same thing.
I will try to explain.

I agree that the connection reuse checking needs to happen *after* the DNS
for a particular transaction. And because of this, a proxy on the left doing
lots of transaction to the right will end up with a connections to all the
proxies on the right.

The problem with the TLS is that a given proxy farm (say the one on the
right) may host several virtual domains. Say it is widgets.org and acme.org.
Now when the left side sends to acme.org, it needs to do the DNS, then look
in the connection cache for a connection to the resolved IP/port, then out
of all the connection to that destination look and see if one is a TLS
connection connected to acme.org. In this example each proxy on the left
could end up with two TLS connections (one for each virtual domain) to each
thing on the right. You can't just use the IP address as the index for the
alias for TLS. 

This is pretty easy to implement in most proxies doing TLS because, after
the DNS resolution is done, you still pass the domain name, along with the
IP address, down to the layer where the transport connection is formed so
that you can check that subjectAltName of the connection is correct.

The final thing has to do with this DNS dialback scheme for TLS - I think it
is, well, useless. Let's say DNS with no security claims that example.com
can resolve to 1.1.1.1 but TLS is connected to a host 2.2.2.2 which has
proven it has the private key for exmaple.com. Which one are you going to
believe? The TLS is a much stronger assertion. Ignoring the what do you
believe, you still don't need to do this dialback check if you do what is
described above because when someone goes to send a request, it will never
resolve the IP to this connection.

On 11/16/04 12:09 PM, "Jonathan Rosenberg" <[email-masked]> wrote:

> During the sip meeting, we had a lot of discussion about the
> interactions between connect-reuse and the RFC 3263 mechanisms for load
> balancing. The current mechanism in connect-reuse will, I believe,
> create a single connection between a proxy in one domain and one of the
> servers in another domain.
> 
> I think the objective of the connect-reuse mechanism is to produce a
> topology that looks like this:
> 
>      Please view in a fixed-width font such as
>                      Courier.
> 
> 
> 
> 
> 
> 
>         +---------+
>         |         |
>         |         |
>         | Proxy   | ---
>         |         |    ------          +---------+
>         |         |\         -----     |         |
>         +---------+ \\            ---  |         |
>                       \                | Proxy   |
>                        \            -- |         |
>                         \\      ----   |         |
>         +---------+       \  ---     / +---------+
>         |         |       -\\       /
>         |         |   ----   \    //
>         | Proxy   | --        \  /
>         |         |            \X
>         |         | --         / \
>         +---------+   ----    /   \
>                           ---/     \\  +---------+
>                            / ----    \ |         |
>                           /      --    |         |
>                          /         --  | Proxy   |
>         +---------+     /       ---    |         |
>         |         |   //    ----       |         |
>         |         |  /   ---           +---------+
>         | Proxy   | / ---
>         |         | --
>         |         |
>         +---------+
> 
> That is, between each proxy in domain A and each proxy in domain B,
> there is a single connection used for traffic in each direction. The
> transaction load is distributed across those connections proportiaonlly
> to the weight factors in the SRV records.
> 
> This effect can be achieved if a connection is aliased to to an IP
> address, so that the connection reuse takes place *after* the DNS
> operations have occurred.
> 
> This means that, when one proxy (A) opens a connection to another (B), A
> has to tell B that, when B wants to send requests to a particular IP
> address, it can use this connection instead. This needs to be done
> securely.
> 
> I'd suggest the following. A opens a TCP connection to a server in B
> (based on the DNS lookup of B's domain). There is a TLS exhcange. A
> indicates to B an IP address for which it is an alias. B takes the
> domain from the subjectAltName in the cert presented by A, looks up the
> domain in DNS, and verifies that the offered IP address is listed in the
> DNS record. If so, it is accepted as an alias.
> 
> -Jonathan R.

_______________________________________________
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: Eric Rescorla <[email-masked]>
Date: Mon, 13 Dec 2004 04:47:27 -0800

> that you can check that subjectAltName of the connection is correct.
It's worth noting that this only works correctly if either:

1. The TLS server has a wildcard or multi-name certificate.
2. You're using the server_name extension from RFC 3546. 

Otherwise you can't use name-based virtual hosts with TLS.

> resolve the IP to this connection.

This sounds correct to me.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Dec 2004 09:31:07 -0700

> Otherwise you can't use name-based virtual hosts with TLS.

Yes. I was assuming more 2 than 1 - we are trying to get this into SIP stuff
but I don't believe anyone has implemented it yet. I think the wildcards are
forbitten in sip but multi-name are allowed. I'm not sure if anyone will use
them.

---

From: Robert Sanders <[email-masked]>
Date: Wed, 15 Dec 2004 12:36:34 -0500

> forbitten in sip but multi-name are allowed. I'm not sure if anyone will use

We have well over 300,000 hosted domains at EarthLink, and around 150
domains in our consumer service.  We absolutely must use the
server_name extension.  I can't imagine us doing TLS without it.  We
might *also* want multi-name, as we currently allow people to use URIs
of the form <user>@sip.<domain> as aliases for <name>@<domain>, where
sip.<domain> has an A record for the proxy for <domain>.  This is
primariy for working around proxies that don't support SRV.  But
multi-name is clearly neither necessary if there is mandatory support
for server_name, nor a sufficient replacement for it.

regards,
  -- Robert

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Dec 2004 08:02:47 -0800

Makes sense - you might want to start pushing this a little because right
now, I am not aware of a single SIP product that supports it. I would
initially encourage UA to at least send the option. That way there will be
UA in place that support when people finally do upgrade to proxies that
support it.