Inline.
Hadriel Kaplan wrote:
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Monday, November 19, 2007 3:25 PM
To: Vijay K. Gurbani
Cc: Hadriel Kaplan; IETF SIP List; Rohan Mahy; Brett Tate
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Vijay K. Gurbani wrote:
Hadriel Kaplan wrote:
I wouldn't. :) It is no more "authenticated" than if the remote end
opened a connection using an ephemeral port to the local host's
listen port. The local host client knows little about the validity
of the remote end. Actually, the client knows slightly more about
the validity of a connection it opened to the far-end than the other
way-around, especially if it did single-sided TLS to the far-end, so
in that sense it makes more sense to accept requests over its client
socket than over the listen port. It just doesn't make much sense
for the remote end to send them over it, unless it can authenticate
(e.g., using digest). And that's the rub. Today certain types of
devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the
client to do sip-outbound, so long as the client can accept requests
over its persistent connection, because they can authenticate the
client. It's worked so far, anyway. But this new MUST would break
it.
Hadriel: So essentially you are arguing for one of the following
positions (assume A makes an active TCP connection to B to send a
request downstream):
1) Allow B to send requests upstream (to A) as long as A can
authenticate B, possibly using HTTP Digest (although how we
will do so if A and B are proxies is an open question.)
2) Downgrade the strength of S8.1 to something like the following:
OLD:
It MUST only accept responses over this connection and MUST NOT
accept any requests over this connection.
NEW:
It accepts responses over this connection, but SHOULD NOT accept
any requests.
The above both seem like nonsense to me. Neither deals with the
essential issue that B has no way of verifying that it is talking to A.
Paul
No, B does have a way of verifying it's talking to A.
B can digest challenge A for the requests it got from A
over that same connection previously.
In general a digest challenge from B to A can't be correlated directly
to the address of A. So a successful response to the challenge won't
help with future reverse routing.
What is the digest challenging?
Lets take a case. Assume we have sip:[EMAIL PROTECTED] calling
sip:[EMAIL PROTECTED] But the call goes first to sip:edge.atlanta.com
(based on some outbound "proxy" configured for alice) and then to
sip:edge.biloxy.com (based on SRV lookup), and then to sip:[EMAIL PROTECTED]
And lets just consider connection reuse between edge.atlanta.com and
edge.biloxi.com. The connection is established in that direction.
edge.biloxi.com *thinks* the name of the previous hop is
edge.atlanta.com because of the Via header. But what digest challenge
can edge.biloxi.com do to verify that the prior hop is who it thinks it is?
As written in the draft,
B has no way to verify it's talking to A when it creates a new
TCP connection to A, other than to believe the TCP listener is A
and SYN/ACK exchange is happening with A.
The original connection was from A to B, and A had no better way to
verify that it was talking to B.
But we don't have to
say anything about this. Just remove the MUST statement in the
draft that A must not accept requests from B over a TCP or
single-sided TLS connection created by A to B. You already say B
must not reuse the connection to A because it's not authenticated.
Leave it at that.
I will agree that this isn't a concern of A's. It is B that has the
concern, and lacks knowledge to reuse the connection. So it is B that we
should be giving MUST NOT or SHOULD NOT instructions to.
I would be ok with saying that B MUST NOT reuse this connection for
requests to the supposed party at the other end UNLESS it has some way
of verifying the identity of that party to the same level of assurance
as it would have by doing the DNS lookup and establishing its own
connection. For instance, if a DNS lookup resolved to the same address
and port as the source port of the inbound connection then that ought be
be good enough.
Thanks,
Paul
I am not arguing this just for the sake of argument. Today this property of
reusing the connection from A to B for requests back to A is already deployed,
and is essential for NAT traversal to work. It works, and is as secure as
could be under the circumstances. A creates a TCP or client-TLS connection to
B. A sends a request, B challenges it, A answers the challenge. B can then
knowingly send requests over the connection to A, and there's no reason for A
to reject them. This is in fact the premise for sip-outbound as well.
-hadriel
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
