6 jul 2011 kl. 22.54 skrev Brez Borland: > Okay, this all gets a little bit complicated and rather interesting. The > following is purely my own reasoning. > > We should not forget that we are talking a TLS layer context here, _not_ TCP. > That is, the underlying TCP connection should not require a continuous > _established_ state. But rather the TCP connection that is utilised by the > TCP context could fail, be re-established, fail gain and so on.. And IMHO the > TLS connection should be considered as being valid, as long as after the > re-connection the remote site resumes with the valid TLS context. > > What I am trying to say, is that at the SIP layer, transactions are _not_ > invalidated if the TCP connection to the remote site goes down. SIP > transaction has it's own context, independent to TCP. So does the TLS. > > So I can't see how TLS connection could be made invalid by anything else but > TLS layer. I mean, can somebody define when TLS connection is broken? Is it > timeout, or something else, cause looking at rfc5246 I can't find anything > related.. > > That's really interesting. Yes, the TCP layer is not interesting in a TLS session, all we care about is the TLS connection state. Now, I don't think TLS can survive a TCP breakdown, but that's something we'll propably have to look into. Anyone that can explain this?
/O > Comments please, > > > Regards, > > Brez > > On Wed, Jul 6, 2011 at 8:11 PM, Olle E. Johansson <o...@edvina.net> wrote: > > 6 jul 2011 kl. 18.19 skrev Iñaki Baz Castillo: > > > 2011/7/6 Olle E. Johansson <o...@edvina.net>: > >> - A proxy (A) forwards a SIP request with a SIPS r-uri to another proxy > >> (B). The VIA header indicates SIPS and has a domain name. The proxy that > >> receives the request shows a server CERT, but doesn't require a client > >> certificate. > >> > >> 1) For the response - can we reuse the connection? > > > > 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. > > > > > > >> 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. > > > > > 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. > > > > > >> 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. > > /O > --- * Olle E Johansson - o...@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
