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