On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo <i...@aliax.net> wrote:
> 2011/7/7 Brez Borland <brez...@gmail.com>: > > I think once TLS context is invalidated(i.e. rejected to be resumed by > Proxy > > A), Proxy B should either: > > > > 1) return an error to the downstream UAS (i.e. failure to send response > > _permanently_), or > > What does mean "return an error to the downstream UAS"? This is, the > UAS has sent to proxy B a SIP response, and proxy B is not able to > forward it to proxy A. How could proxy B "return an error to the UAS"? > There is no SIP mechanism for that, do I miss soemthing? > You are right, I meant to say that Proxy B should just drop the response. This is as per rfc3261, Section 16.9. > > 2) not perform validation of the upstream element cert. Because by > > forwarding a response, by definition, it acts as a server in this > particular > > transaction(request, and any responses to it). > > > > Why one would care validating a certificate of an upstream element when > > forwarding a response, if one doesn't case about that validity when he's > > forwarding a request? > > It could occur that proxy A presents to proxy B a client TLS > certificate owning domain atlanta.com, and then proxy A routes a > request witth From domain "atlanta.com" to proxy B. Let's also suppose > that the Via contains "myserver.org" in sent-by-host. > > proxy B cannot forward a response to proxy A using the TLS connection > so resolves myserver.org and connects there using TLS. Then proxy A > shows a certificate for domain atlanta.com rather than myserver.org. > Should proxy B allow it? > Proxy B should not discard data(certificates previously received) associated with Proxy A when it tries to reconnect to it. I think Proxy B should retain the certificate atlanta.com, and have it associated with myserver.org, at least for the lifetime of transaction. So after resolving and connecting to myserver.org it could compare the newly received certificate atlanta.comwith the one in caches. Regards, > > Anyhow, I agree that it does not make sense to verify a certificate > when sending a response using the fallback mechanism (sending it to > the Via sent-by-host). > > > > > > > >> - Then open a TLS connection with the resolved adrress (proxy A). > >> > >> - Upon TLS connection, proxy A would show its certificate, so it would > >> fail in case the Via sent-by-host was an IP rather than a domain > >> matching a domain in the certificate (complex, ugly, unfeasible). > > > > > > We could be trying to connect to the last upstream element here, the UAC, > > which might not have a valid cert. > > Right. > > -- > Iñaki Baz Castillo > <i...@aliax.net> > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
