Cullen Jennings wrote:
Big question ...
[...]
I don't think this works from some TLS situations. If a proxy is
hosting two virtual domain red and blue both with TLS and use the
same port for both using the extended hellos TLS options.
Cullen: Thanks for being persistent on this one. This situation
was listed as an open issue at the Dallas IETF presentation
(see http://www3.ietf.org/proceedings/06mar/slides/sip-6.pdf).
So, I think we can solve this with some work. More inline; I
will preserve the description of the problem you provided for
context.
Now both the red and blue domains have a user called tel:1234 but we
don't want red tel:1234 to get IMs meant for blue. Blue sends an IM
to Alice at some other domain. This forms an alias to the server.
Now Red bob sends an IM to Alice - this updates the alias and
basically hijacks blue. When ALice relies to blue, the proxy in
Alice's domain will mistakenly select the TLS connection that was
formed by red domain since it goes to the correct ip address, port,
and transport. The virtual domain that servers red and blue will
process the request in the context of red since it received it over
a TLS connection that is part of the red domain. You might say this
is a corner case but hosting multiple virtual domains this way is
very desirable and the HTTP people have been working hard to make
this easier to deploy. The latest version of common TLS libraries
are starting to support this and I expect to see more servers that
can do this. (PS. I think I have mentioned this on several different
versions of this document - let me know if I am not making any
sense)
In order to arrive at how to solve this, the idea from Jonathan's
email about a server caching client certificates for later
use come into the picture. Here are the steps:
1) We have a proxy P that has two virtual domains -- red.com
and blue.com -- accessible at port 5061 (note that in the
scenario we are talking about, the destination port really
does not matter. The problem arises when P sends *out*
requests from its respective domains to a third party, and
that third party wants to re-use the ensuing connection for
requests in the backwards direction).
1a) P has a physical address of 192.168.1.2.
2) red.com has a user with a URI of sip:bob at red.com.
3) blue.com has a user with a URI of sip:bob at blue.com.
4) Now, bob at blue.com sends out a request to Alice through P:
MESSAGE sips:alice at P2.com SIP/2.0
From: <sips:bob at blue.com>;tag=8uxy--y6
Via: SIP/2.0/TLS blue.com;branch=...
...
5) Alice's proxy (P2) gets the request and creates an alias:
Dest. Dest. Dest. Dest. Alias
Address Port Transport Certificate Descriptor
192.168.1.2 5061 TLS blue.com 28
Note the new column (Dest. Certificate) -- this is key to
solving this particular problem. The certificate from
blue.com is cached by P2, and the domain name in the column is
got from either the Via, or better yet, from the SAN in the
certificate.
Now requests from P2 towards the blue.com:5061 domain will go through
the alias descriptor 28, which is tied to 192.168.1.2:6666 (port
6666 being the source port chosen by the sending TCP).
6) At some later time, bob at red.com sends a request to Alice through
P:
MESSAGE sips:alice at P2.com SIP/2.0
From: <sips:bob at red.com>;tag=9j7-y6
Via: SIP/2.0/TLS red.com;branch=...
...
7) Alice's proxy (P2) gets the request and updates its alias
table with a new row:
Dest. Dest. Dest. Dest. Alias
Address Port Transport Certificate Descriptor
192.168.1.2 5061 TLS blue.com 28
192.168.1.2 5061 TLS red.com 32
Requests from P2 towards the red.com:5061 domain will go
through the alias descriptor 32, which is tied to 192.168.1.2:7777
(port 7777 being the source port chosen by the sending TCP).
8) When P2 wants to send a request in the opposite direction, it
will run the next hop URI through rfc3263 resolution. That
resolution will result in an IP address/port/transport
(192.168.1.2:5061:TLS). But instead of simply sending it to
the first such row from the alias table, P2 will need to
authenticate the URI used in the rfc3263 resolution to the
appropriate certificate in order to choose the right descriptor.
Thus, P knows that all requests coming in the backwards direction
over 192.168.1.2:6666 belong to blue.com and those arriving over
192.168.1.2:7777 belong to red.com.
I know this makes for a rather complex set of gyrations, but if
we want to support name-based virtual servers, then this is one
way that accounts for the requirements listed in Section 6
of the connect-reuse draft. If there are better and more elegant
ways to do this, I would love to hear them.
Thoughts?
Thanks.
- vijay
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip