Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Aug 2006 13:44:59 -0700

Big question ...

If the proxies always did this regardless of if there was an alias  
tag in the via or not, would everything work? I could not find  
something that did not work but I could easily be missing the  
obvious. I do note that alias indicates you want a long lived  
connection but everyone always wants to be long lived so we could  
just assume that.

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. 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)

Seems like we should be more blunt up front that this does not work  
for TCP and can only be used for TLS

Few trivial things ...

Section 6

point 2 - since this is proxy to proxy, not sure this is relevant

point 3 - seems like the if an ephemeral port is used, the mechanism  
will never share it so I don't think this requirement is satisfied.  
On the other hand, I don't think it matters that is is not satisfied.

Section 8

para 2 - you use "default port if it does not" - I don't think this  
is right - it needs to be the port it was received from or  you have  
a hijack issue.

Section 9.1 - not sure this is exactly right but it seems like this  
is all a 3261 issue not really a connection reuse issue

Section 9.2 introduces the term "canonical host name of the server"  
without defining it but I think this is sort of wrong. The thing that  
is in the cert needs to match whatever was put in the VIA. No more,  
no less. For some deployments, this will be a DNS names that refers  
to that specific server, for others it might refer to many servers.

Section 9.2 is pretty wimpy about saying don't do this with TCP. How  
about something with some normative language like

  "This mechanism MUST NOT be used for TCP connections because there  
is no way to perform the authentication step"

You say to send a 403 if the client can not provide a certificate,  
but what if it provides one but it is not signed by something in the  
root list of the server or is invalid in some other way (such as  
expired).

_______________________________________________
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, 07 Aug 2006 09:11:37 -0500

Cullen Jennings wrote:
> 
> Big question ... If the proxies always did this regardless of if
> there was an alias  tag in the via or not, would everything work? I
> could not find  something that did not work but I could easily be
> missing the  obvious. I do note that alias indicates you want a long
> lived  connection but everyone always wants to be long lived so we
> could  just assume that.

Cullen: If the alias parameter was not in the Via header,
I suspect things will work just as well assuming that the
sender of the request leaves its connection open beyond the
transaction/dialog lifetime (while majority of proxies may,
not all do).  However, I lean towards making the intent of
a feature more explicit, if possible, in the signaling.  So,
a proxy receiving a request with an "alias" parameter can
deterministically know the behavior of its peer.  All things
being equal, I would rather leave the parameter in there.

> I don't think this works from some TLS situations.
[...]
> (PS. I think I  have mentioned this on several different versions of
> this document -  let me know if I am not making any sense)

Thanks for being persistant with this example; yes, it is in
my list of things to close down in the next rev of the draft.

I am spending this week rev'ing the draft, so I suspect that I
will address this question successfully, or failing that, open
up a dialog on the mailing list about it.

> for TCP and can only be used for TLS

Noted; will wordsmith them in.

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: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 Aug 2006 17:04:45 -0500

[...]
> 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:[email-masked].

3) blue.com has a user with a URI of sip:[email-masked].

4) Now, [email-masked] sends out a request to Alice through P:
  MESSAGE sips:[email-masked] SIP/2.0
  From: <sips:[email-masked]>;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, [email-masked] sends a request to Alice through
  P:
  MESSAGE sips:[email-masked] SIP/2.0
  From: <sips:[email-masked]>;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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 10:34:30 -0700

Yes - this solves it. The key thing is the table has to store the  
name (or names) from the TLS cert and that when you go to reuse the  
connection, you can only reuse it if the target you are sending to if  
it matches this name from the cert.

Now, assuming we did this, it brings up some other questions which I  
don't really feel that strongly about - why bother storing the IP and  
port in the table? If you have a connection to that domain, just use  
it. I realize that stops the distribution of load from a single proxy  
to farm but it's not clear to me if that is a bug or a feature. If  
the goal is to reduce number of connections and still have  
reliability - it is a feature. If you have a bunch of proxies all  
sending to a bunch of proxies, they will likely end up somewhat load  
balanced anyways. It would significantly reduce the complexity of  
this draft to describe it that way. I'm ok with the draft going any  
one of the following direction on this 1) always do all the DNS stuff  
resulting in O(n^2) connection between two farms that both had n  
proxies 2) don't keep the IP and port in the table resulting in O(n)  
connection between two farms that both had n proxies 3) let it be an  
configurable option.

No matter what way we go, your proposal here solves the security  
problem and I like it.

Thanks, Cullen

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Aug 2006 14:16:46 -0400

Cullen Jennings wrote:
> 
> Yes - this solves it. The key thing is the table has to store the name 
> (or names) from the TLS cert and that when you go to reuse the 
> connection, you can only reuse it if the target you are sending to if it 
> matches this name from the cert.

(Sorry if this makes no sense - my knowledge of TLS is feeble.)

I am confused by Vijay's example because it shows the entries for 
red.com and blue.com being established independently. They have the same 
address and port, and it isn't clear if they share a connection.

I would think that Bob's proxy would only establish one connection to 
Alice's proxy, and that the TLS handshake would provide all the 
identities that Bob's proxy has. (red.com and blue.com)

> port in the table? If you have a connection to that domain, just use it. 
> I realize that stops the distribution of load from a single proxy to 
> farm but it's not clear to me if that is a bug or a feature.

I don't see how you can use any but the established connections in any 
case. You only have the identity via the handshake on the connection you 
have. If that goes away you will need to establish a new connection and 
exchange credentials again. The establishment will be driven by 3264 - 
no need for the table - and then a new table entry will be established.

So I think you are right to only keep the connection in the table.

	Paul

> If the goal 
> is to reduce number of connections and still have reliability - it is a 
> feature. If you have a bunch of proxies all sending to a bunch of 
> proxies, they will likely end up somewhat load balanced anyways. It 
> would significantly reduce the complexity of this draft to describe it 
> that way. I'm ok with the draft going any one of the following direction 
> on this 1) always do all the DNS stuff resulting in O(n^2) connection 
> between two farms that both had n proxies 2) don't keep the IP and port 
> in the table resulting in O(n) connection between two farms that both 
> had n proxies 3) let it be an configurable option.
> 
> No matter what way we go, your proposal here solves the security problem 
> and I like it.
> 
> Thanks, Cullen
> 
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 09 Aug 2006 14:10:14 -0500

Cullen Jennings wrote:
> connection, you can only reuse it if the target you are sending to
> if it matches this name from the cert.

Yes.

>  don't really feel that strongly about -
[...]
> I'm ok with the draft going any  one of the following direction on
> this 1) always do all the DNS stuff  resulting in O(n^2) connection
> between two farms that both had n  proxies 2) don't keep the IP and
> port in the table resulting in O(n)  connection between two farms 
> that both had n proxies 3) let it be an  configurable option.

My preference is (1) since it does not disrupt SRV load balancing.
After all the rfc3263 gyrations, you will always end up with an {IP
address, port, transport} tuple.  And if you have that information
saved already, you can always avail of it to make an intelligent
decision.

If the WG prefers, it can be mentioned in the draft that
(2) is an option as well, and allow implementations to choose
it with appropriate caveats.

> No matter what way we go, your proposal here solves the security 

OK.  I will put this into the draft.

Thanks for your time in a quick turnaround.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 09 Aug 2006 14:10:17 -0500

> address and port, and it isn't clear if they share a connection.

No, they don't share a connection; that is, red.com and P2 share a
connection that is distinct from the one shared by blue.com and P2.

Yes, the address and port for red.com and blue.com are the same
in P2's table (because it is the same physical server, albeit
with multiple personalities), but think of these as an index that
P2 uses to see if it has an existing connection already open to a
certain IP address/port/transport tuple (resulting from an
rfc3263-lookup on a URI).  If it does, then an additional check
for a cached cert would be done.

> identities that Bob's proxy has. (red.com and blue.com)

No; it should be one certificate per virtual domain.  When P
(Bob's proxy) makes a connection to P2, it can have policies on
which certificate to present to P2, if asked.

In the same vein that using TLS extended hello, a client can
ask the server for a certificate corresponding to a particular
domain.

Thanks.

- vijay