2011/7/6 Olle E. Johansson :
> One can imagine a large number of failures here if one messes with Contact:,
> Record-route and Route headers and others. RFC 6216 is not very helpful:
An interesting point I've found reading RFC 6216:
6. Additional Test Scenarios
o IP addresses can appear
2011/7/8 Olle E. Johansson :
>> I think it's the best choice as I expect that a retranmission coming
>> via other connection means that the client has lost the initial
>> connection and expects responses in the new one.
>>
> Well. If one of the two outbound proxys the client is using dies,
> retra
7 jul 2011 kl. 20.22 skrev Iñaki Baz Castillo:
> 2011/7/7 Iñaki Baz Castillo :
>> 2011/7/7 Iñaki Baz Castillo :
>>> 2011/7/7 Brez Borland :
I think transport/transaction layers should work to prevent cases like
this.
Personally I would look to close the previous connection associa
On Thu, Jul 7, 2011 at 7:22 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Iñaki Baz Castillo :
> > 2011/7/7 Iñaki Baz Castillo :
> >> 2011/7/7 Brez Borland :
> >>> I think transport/transaction layers should work to prevent cases like
> this.
> >>> Personally I would look to close the previous connect
2011/7/7 Iñaki Baz Castillo :
> 2011/7/7 Iñaki Baz Castillo :
>> 2011/7/7 Brez Borland :
>>> I think transport/transaction layers should work to prevent cases like this.
>>> Personally I would look to close the previous connection associated with the
>>> transaction, and use the new connection for
2011/7/7 Iñaki Baz Castillo :
> Mmmm, danger, what about if the first connection is opened by a proxy
> which currently mantains more than one transaction with the server?
> why to close such connection just because a retransmission of some one
> of those transactions has arrived via other connecti
2011/7/7 Iñaki Baz Castillo :
> 2011/7/7 Brez Borland :
>> I think transport/transaction layers should work to prevent cases like this.
>> Personally I would look to close the previous connection associated with the
>> transaction, and use the new connection for any further associated
>> communicat
2011/7/7 Brez Borland :
> I think transport/transaction layers should work to prevent cases like this.
> Personally I would look to close the previous connection associated with the
> transaction, and use the new connection for any further associated
> communications.
It could be a good choice.
-
On Thu, Jul 7, 2011 at 6:00 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Kevin P. Fleming :
> > If we're talking about TCP here (as I believe we are, since DTLS isn't
> > part of the discussion yet), then the server also knows that the
> > original connection has been lost. There is only one connecti
2011/7/7 Kevin P. Fleming :
> If we're talking about TCP here (as I believe we are, since DTLS isn't
> part of the discussion yet), then the server also knows that the
> original connection has been lost. There is only one connection to use
> to send the response back... the new one that the client
On 07/07/2011 10:59 AM, Iñaki Baz Castillo wrote:
> 2011/7/7 Olle E. Johansson:
>> Maybe the only solution here is just to drop the response and hope that the
>> UAC retransmits the request and keeps a useful connection open.
>
> ...and then it comes another question I asked in this maillst:
>
> -
2011/7/7 Olle E. Johansson :
> Well, if the via was a dns name, it could resolve in both IPv4 and IPv6 :-)
Or in lot of them! :)
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.
7 jul 2011 kl. 18.04 skrev Iñaki Baz Castillo:
> 2011/7/7 Olle E. Johansson :
>> Right so the question is if we can add a valid domain in the Via - one that
>> matches the cert.
>
> The Via header is added (usually) by the transaction layer (who knows
> which transport to use and so). But the c
2011/7/7 Olle E. Johansson :
> Right so the question is if we can add a valid domain in the Via - one that
> matches the cert.
The Via header is added (usually) by the transaction layer (who knows
which transport to use and so). But the core layer (the proxy) could
handle many domains. So it's ha
7 jul 2011 kl. 17.56 skrev Iñaki Baz Castillo:
> 2011/7/7 Olle E. Johansson :
>> Well, the question is what to put in the Via header. You need something that
>> points back if you have transaction state in one of your proxys... The
>> received parameter helps with that.
>> You don't want to ha
2011/7/7 Olle E. Johansson :
> Maybe the only solution here is just to drop the response and hope that the
> UAC retransmits the request and keeps a useful connection open.
...and then it comes another question I asked in this maillst:
- The connection is terminated and let's assume cannot be re
2011/7/7 Olle E. Johansson :
> Well, the question is what to put in the Via header. You need something that
> points back if you have transaction state in one of your proxys... The
> received parameter helps with that.
> You don't want to have IP addresses or host names in certs either. So
> -w
7 jul 2011 kl. 17.15 skrev Brez Borland:
> On Thu, Jul 7, 2011 at 3:56 PM, Olle E. Johansson wrote:
> > Why would Proxy B want to _validate_ the certificate of Proxy A if it have
> > not done so when Proxy A established a connection? Proxy B might want to
> > _verify_ that Proxy A presented th
7 jul 2011 kl. 16.28 skrev Iñaki Baz Castillo:
> 2011/7/7 Olle E. Johansson :
>>> 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
On Thu, Jul 7, 2011 at 3:56 PM, Olle E. Johansson wrote:
> > Why would Proxy B want to _validate_ the certificate of Proxy A if it
> have not done so when Proxy A established a connection? Proxy B might want
> to _verify_ that Proxy A presented the same certificate when Proxy B falls
> back.
> Pr
2011/7/7 Olle E. Johansson :
> I really, really need to write this all down somewhere just to remember.
Yes, I will make a website with all this stuff. Just let me some time.
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@li
7 jul 2011 kl. 16.50 skrev Iñaki Baz Castillo:
> 2011/7/7 Brez Borland :
>> Why would Proxy B want to _validate_ the certificate of Proxy A if it have
>> not done so when Proxy A established a connection? Proxy B might want to
>> _verify_ that Proxy A presented the same certificate when Proxy B f
2011/7/7 Olle E. Johansson :
>> Why would Proxy B want to _validate_ the certificate of Proxy A if it have
>> not done so when Proxy A established a connection? Proxy B might want to
>> _verify_ that Proxy A presented the same certificate when Proxy B falls back.
> Proxy A sets up a connection to
7 jul 2011 kl. 16.45 skrev Brez Borland:
> On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson wrote:
>
> > > 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, an
2011/7/7 Brez Borland :
> Why would Proxy B want to _validate_ the certificate of Proxy A if it have
> not done so when Proxy A established a connection? Proxy B might want to
> _verify_ that Proxy A presented the same certificate when Proxy B falls
> back.
Even if proxy-A has presented a valid ce
On 07/07/2011 09:45 AM, Brez Borland wrote:
> Why would Proxy B want to _validate_ the certificate of Proxy A if it have
> not done so when Proxy A established a connection? Proxy B might want to
> _verify_ that Proxy A presented the same certificate when Proxy B falls
> back.
>
> If connection is
On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson wrote:
> > > 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 ca
2011/7/7 Olle E. Johansson :
>> 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 t
7 jul 2011 kl. 14.11 skrev Brez Borland:
> On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Brez Borland :
> > 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. f
On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Brez Borland :
> > 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_)
2011/7/7 Brez Borland :
> 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
On Thu, Jul 7, 2011 at 9:34 AM, Iñaki Baz Castillo wrote:
> 2011/7/6 Olle E. Johansson :
> >> 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 -
2011/7/7 Olle E. Johansson :
>>> 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.
> We're still talking
7 jul 2011 kl. 10.34 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson :
>>> 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
2011/7/6 Olle E. Johansson :
>> 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'
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 requ
Ok, here's the thing. rfc5246, Section F.1.4, says TLS session context
lifetime can be up to 24hours.
So TCP connection between the server and the client can be down for a way
longer period of time than the SIP session. If the Proxy B wants to forward
the response back to the Proxy A and TLS finds
On Wed, Jul 6, 2011 at 9:54 PM, Brez Borland wrote:
> .. by the TCP context could fail,
I meant "TLS context"...
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implemen
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 TC
6 jul 2011 kl. 18.19 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson :
>> - 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
2011/7/6 Olle E. Johansson :
> - 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
On Wed, Jul 6, 2011 at 4:54 PM, Olle E. Johansson wrote:
>
> 6 jul 2011 kl. 17.28 skrev Brez Borland:
>
> > On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo
> wrote:
> > 2011/7/6 Olle E. Johansson :
> > >> Good question. However, checking a server certificate (matching the
> > >> domain) just
6 jul 2011 kl. 17.28 skrev Brez Borland:
> On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo wrote:
> 2011/7/6 Olle E. Johansson :
> >> Good question. However, checking a server certificate (matching the
> >> domain) just makes sense (IMHO) for requests. This is, an UAC sends a
> >> request to
On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo wrote:
> 2011/7/6 Olle E. Johansson :
> >> Good question. However, checking a server certificate (matching the
> >> domain) just makes sense (IMHO) for requests. This is, an UAC sends a
> >> request to a proxy/server (depending Route or RURI). Th
2011/7/6 Olle E. Johansson :
>> Good question. However, checking a server certificate (matching the
>> domain) just makes sense (IMHO) for requests. This is, an UAC sends a
>> request to a proxy/server (depending Route or RURI). The proxy/server
>> presents a TLS certificate including N certified d
6 jul 2011 kl. 16.26 skrev Brez Borland:
> Hi Olle, please see below..
>
> On Wed, Jul 6, 2011 at 3:15 PM, Olle E. Johansson wrote:
>
> 6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo:
>
> > 2011/7/6 Olle E. Johansson :
> >> Now, consider that a UA has configured a proxy as an outbound proxy. T
Hi Olle, please see below..
On Wed, Jul 6, 2011 at 3:15 PM, Olle E. Johansson wrote:
>
> 6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo:
>
> > 2011/7/6 Olle E. Johansson :
> >> Now, consider that a UA has configured a proxy as an outbound proxy. The
> connection between them is out of scope for n
6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson :
>> Now, consider that a UA has configured a proxy as an outbound proxy. The
>> connection between them is out of scope for now.
>>
>> The UA issues a call to SIPS:al...@georgia.example.com
>> The proxy does NAPTR/SRV
2011/7/6 Olle E. Johansson :
> Now, consider that a UA has configured a proxy as an outbound proxy. The
> connection between them is out of scope for now.
>
> The UA issues a call to SIPS:al...@georgia.example.com
> The proxy does NAPTR/SRV resolution and comes up with a server that presents
> a
During a discussion with OpenSER/Kamailio developers about TLS and SIPS we've
come up with a number of issues we can't sort out.
Now, consider that a UA has configured a proxy as an outbound proxy. The
connection between them is out of scope for now.
The UA issues a call to SIPS:al...@georgia.e
50 matches
Mail list logo
