Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try

From: "Stastny Richard" <[email-masked]>
Date: Fri, 9 Dec 2005 13:17:27 +0100

Thanx Klaus

for the work ;-)

Now the next question:
What are the implications proxy vs redirect
if you are using TLS?
 
Richard

________________________________

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Fr 09.12.2005 12:52
An: Stastny Richard
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try

Stastny Richard wrote:
> Thanx Klaus
>
> Also for answering a question I did not (yet) ask
> regarding redirect vs proxy
>
>
>
>>I personally prefer relaying instead of redirect.
>
>
> Me too and I see your arguments.
> Are there any arguments out there why to prefer redriect?

I just made some signaling pictures to visualize the difference:
 From the signaling, there is no big difference. Both versions do need
approximately the same amount of signaling packets sent (depends onthe
actual SIP network design).

I do not see any technical reason why to prefer one version over the
other. It's just a personal preference.

regards
klaus

UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
|        |          |                  |             |        |      |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |                  |             |        |        |
|        |          |<------302--------|             |        |        |
|        |<-302-----|-------ACK------->|             |        |        |
|        |--ACK---->|                  |             |        |        |
|        |--INVITE->|                  |             |        |        |
|        |<-100-----|--------------INVITE----------->|        |        |
|        |          |<--------------100--------------|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |<---------------180-------------|        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |<---------------200-------------|        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |

32 Packets

UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
|        |          |                  |             |        |        |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |<-------100-------|---INVITE--->|        |        |
|        |          |                  |<----100-----|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |                  |<---180------|        |        |
|        |          |<----- -180-------|             |        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |                  |<---200------|        |        |
|        |          |<-------200-------|             |        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|

29 Packets

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 09 Dec 2005 13:40:54 +0100

> What are the implications proxy vs redirect

Now it's getting complicated ;-)

With the redirect server, there will be 2 TLS handshakes:
   1. borderProxyA       redirectProxy
   2. borderProxyA       borderProxyB

With the forwarding proxy, one TLS connection is mandatory:
   1. borderProxyA       forwardingProxy

If the forwardin proxy is within the network of provB, there is no need 
to use TLS inside the network of prov if other means can be used to 
authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of 
signaling for in-dialog messages, there is also a must for the second 
TLS conenction between
   2. borderProxyA       borderProxyB

The more complicated thing is the certificate validation. RFC 3263 
mandates, that the SIP domain (before NAPTR, SRV lookups) must be 
identical to the domain in the certificate. If provB hosts thousands of 
SIP domains for its clients, e.g. sip:[email-masked], 
sip:[email-masked], .... and requires TLS for incoming connections, 
provB must present a valid certificate for all hosted domains. Thus, you 
have to give your private key for stastny.com to you SIP provider. 
Furthermore, plain TLS requires the server to send the certificate 
without any knowledge of which domain the UAC is trying to contact. 
Thus, provB needs a dedicated socket for each hosted domain on its 
border proxy to differ the requests and present the proper certificate. 
IMO that does not scale. It can be avoided using the "server_name" TLS 
extension, but this is e.g. not supported in openssl which is used most 
for proxy servers.

This could be also solved by changing RFC 3263 to validate the 
certificate against the domain name revealed after SRV lookups. This was 
forbidden to detect DNS spoofing, but IMO DNS problems should be fixed 
in DNS, not in SIP.

regards
klaus

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 21:47:29 -0800

Seems to me that the redirect model, with TLS, provide much more information
to the parties about the level of trust. It allows a two separate trust
transaction between two parties instead of a three way transitive trust
problem that TLS has no machinery to deal with.

On 12/9/05 4:17 AM, "Stastny Richard" <[email-masked]> wrote:

> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum