2011/7/6 Olle E. Johansson <o...@edvina.net>: >> Yes, always. Responses for request arrived via TCP/TLS/SCTP must reuse >> the same connection if available.
> But SIP outbound says that this only applies when we have mutual TLS > identification - client and server certificate. Correct me if I'm wrong, but I don't think that SIP outbound requires each UA/client to have an own certificate. >>> 2) If the connection is lost, does proxy B has to open a new TLS >>> connection back to A, validating A's certificate agains the via header? >> >> IMHO it must easier don't perform such exotic step in RFC 3261. This >> is, if the response cannot be sent using the same connection, the >> client (proxy A) should realize that the connection is closed and >> should/could terminate current transaction and generate a new one. > > Well, one of the benefits with stateless proxies and load balancing using SRV > is that you can in fact activate fail over even for responses. What you say > breaks this. Yes, I know. I just think that "failover in responses" is a too much exotic stuf. Never seen that working, never. Also, in any other internet protocol there is no "failover for responses". >> I've seen no implementation performing such fallback mechanism for SIP >> responses (which usually never work due to common NAT scenarios and >> so). > We're talking proxy to proxy. The UA might be behind NAT, but in this > scenario I am assuming no NAT between the proxys. Ok, in this case, if proxy B attemps to send a response to proxy A and the TLS/TCP connection has been closed: - Proxy B must perform RFC 3263 resolution stuf for the Via sent-by-host (exotic). - 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). - If it goes ok, then send the response. >>> 3) for a request from the UA behind proxy B to the UA behind proxy A >>> (contacts use TLS, record-route use TLS), can we reuse the existing >>> connection that was used for the connection from proxy A to proxy B? >> >> Only if proxy A uses ";alias" parameter in Via header and proxy B >> validated the TLS certificate given by proxy A during the request >> sending. >> > RIGHT! Which means that you require client certificate when proxy A sets up > the connection to proxy B. We agree here. That's mandatory in order to reuse the same TLS connection for sending requests in both directions. However, client/server certification validation could occur in any case. A proxy B could be configured to require and validate certificate from proxy A. This becomes funny when: - Proxy A connects TLS to proxy B. - Proxy A validates certificate of proxy B. - Proxy A sends its certificate to proxy B. - Proxy B verifies certificate of proxy A (but take into account that there is no SIP request yet, so can only verify cert expiration, signature and so). - After validation, proxy A sends a request with From (or PAI, or ...) a specific domain xxx.org. - Proxy B now must *authorize* such request (it would inspect the cert of proxy A and lockup for xxx.org domain within it). - If so, the request is authorized. If not => 403? (but the TLS connection remains open, I hope). - Later proxy A could send another request with a different originator domain (in From) to proxy B. - Authorization in proxy B should be performed for *each* received request. So, initially there is cert validation (signature, expiration, revocation...). Later, for each SIP request there must be authorization (based on request originator domain and domains included within the validated certificated). I suppose XMPP works in this way when using federation between different domains. -- 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
