> -----Original Message----- > From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 20, 2007 10:26 AM > To: Hadriel Kaplan > Cc: Paul Kyzivat; IETF SIP List; Rohan Mahy; Brett Tate > Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt > > Trying to drill down to the mechanics of how this will work so the > draft can be updated... > > Hadriel Kaplan wrote: > > 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. > > What if A and B are proxies? Digest will not work in that case.
True enough. (well... actually some proxies are digest challenged, but they essentially act as UA's for that, and obviously it requires a shared secret) I was just responding to Paul when he said B has no way to authenticate A. And B may well have local configuration which tells it that A is who it thinks it is. For example this is sometimes the case for SIP-PBX connections to providers. The PBX is essentially a proxy (ie, "Proxy A"), and is sometimes behind a firewall, and the TCP connection from it to the provider's proxy B needs to be reused for requests to the Enterprise due to that firewall. Certain machinations occur to keep that TCP connection up and re-open it if it fails, but essentially the validity of using it for requests to the Enterprise is provisioned or somehow known by Proxy B. I'm not asking any of that be specified, defined, etc. I'm just using a real-world example, to say there are cases where B knows (or thinks it knows) who Proxy A is. > > 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. > > Problem is that this challenge-response mode in SIP is defined > in HTTP Digest, and that is applicable only between a proxy/registrar > and a UA. What happens if A and B are proxies? Or am I missing > something? I think the disconnect is you're trying to say proxy A should police the behavior of proxy B? Proxy B may or may not have a legitimate reason for sending a request to proxy A on A's client TCP/TLS connection. The draft should and does say B shouldn't do this, but of course that can always be overridden by B's local policy (ie, it may know better). If it has such a policy, there is really no reason A shouldn't allow it. Even if it DOESN'T have such a policy, there is really no reason A shouldn't allow it. There is nothing damaging to A, nor A's domain, about accepting a request over that connection vs. its listen socket. It's B's responsibility and fault if it sends requests to the wrong agent. It's not A's role or fault for accepting them. It's up to proxy B to figure out who/where proxy A is. It's not up to proxy A to second-guess what B thinks it knows. Proxy A knows who Proxy A is. -hadriel p.s., sorry for sticking on this point, it's just that when we get into debates with other vendors over interop issues in the field, RFCs are the tie-breakers; and these seemingly innocuous statements in RFCs often come back to bite us. :( _______________________________________________ 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
