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

From: "Stastny Richard" <[email-masked]>
Date: Fri, 9 Dec 2005 15:28:59 +0100

Now my next question:
 
Is the problem Klaus described below a problem to be sovled within
the SPEERMINT problem (scope) space?
 
"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."

Richard

________________________________

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Fr 09.12.2005 13:40
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
>
> for the work ;-)
>
> Now the next question:
> What are the implications proxy vs redirect
> if you are using TLS?

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

> 
> 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 15:40:10 +0100

> the SPEERMINT problem (scope) space?

IMHO yes, as long as the SIP WGs do not provide a solution which fit 
real life scenarios.

klaus