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
Is that an accurate representation of your concern? Given that the
problem of using HTTP Digest between proxies is a complete new
can of worms, the downgrade option seems more attractive. Would be
nice to hear other opinions.
Thanks,
- vijay
_______________________________________________
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
