Aki Niemi wrote:
> On Wed, 2007-01-17 at 09:20 -0500, ext Paul Kyzivat
wrote:
>> If the connection is direct from UA to registrar,
then perhaps the
>> registration is sufficient to authenticate the
connection for reverse
>> traffic. If the connection is from UA to proxy then
the proxy has to
>> make leaps of faith to trust the identity of the
connection.
>
> I can't see this being any different with UDP, where
the proxy in
> between can effectively be an open relay, and has to
trust the flows it
> relays.
In UDP, outbound requests from the registrar go to the
registered
contact address. It has to be resolved by the last proxy,
and (in the
absence of -outbound-) is independent of how the register
was delivered.
If you try to reuse a tcp connection for requests in the
reverse
direction, then the destination is the source port for the
tcp
connection, which has no direct relationship to the
registered contact.
There are various exploits for this, that permit somebody to
hijack
requests.
For instance: suppose good UA GUA uses a proxy P and
registers to
registrar R, using AOR sip:gua r.
Then an evil UA - EUA could collude with an evil server ES
to hijack
requests outbound from R and intended for GUA. It could
establish a TCP
connection to P, and then send a REGISTER To: sip:guar, but
with a
Route header that takes it to ES, and with a copy of the
contact used by
GUA. ES then colludes by accepting that registration. At
this point, P
will think that the TCP connection from EUA is a valid path
to gua.
The details of this are all tied up in how you decide which
requests can
reuse the tcp connection. You can probably tighten things up
to solve
the above problem. If you work at it enough, I think you
will end up
with something like sip outbound. Rohan attempted, and was
shot down.
You can't just naively say that the connection can be reused
for
requests in the reverse direction.
> But I also can't see how this problem is any different
for, say, HTTP
> proxies. That's why many HTTP proxies are configured to
do
> proxy-authentication, limit the ports to which clients
can CONNECT, etc.
> Similar logic can be added to a SIP proxy to ascertain
that they not
> become a totally open relay.
I don't know much about HTTP implementation, but afaik there
is nothing
like the reverser routing that we are talking about here. So
I don't see
the analogy.
Paul
> The rule of thumb in doing this is that you don't
commit expensive
> resources, or allow all possible actions to be taken
until the
> connection, or flow, is considered trusted.
>
> <snip>
>
>> AFAIK the current version of connection reuse is
primarily of interest
>> for proxy-proxy connections. People keep wanting to
apply it to UAs,
>> apparently as a poor-man's-outbound. There may be a
*few* cases where
>> that can work. But attempting to do so is likely to
just get people
>> confused. I think we would be better off clearly
partitioning the
>> applicability of these two things.
>
> Yes, I agree. As I said in the past, we in practice
have two very
> different interfaces to a proxy: the client-to-server,
and the
> server-to-server. Outbound is for the former;
conn-reuse for the latter.
> Neither one has a problem with TCP, although the way
one determines when
> to trust a connection is very different for each.
>
> Cheers,
> Aki
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|