Subject: RE: [Sip] loop fix

From: Jeroen Van Bemmel <[email-masked]>
Date: Mon, 11 Sep 2006 09:21:23 +0200

RFC3261 proxies can also route by prepending a Route header, without rewriting the request URI. In fact, this is the only way when the proxy is not responsible for the domain

Regards,
Jeroen

-----Oorspronkelijk bericht -----
Van: "Juha Heinanen" <[email-masked]>
Aan: "Thomas Leseney" <[email-masked]>
CC: [email-masked]
Verzonden: 8-9-06 17:01
Onderwerp: Re: [Sip] loop fix

Thomas Leseney writes:

 > Not necessarily. An IMS S-CSCF may proxy a request to several AS.
 > Call id, from tag and RURI do not change. Internal state of the S-CSCF
 > ensures that the request spirals but does not loop.

IMS example doesn't count to me.  give me an example in regular rfc3261
environment.

-- juha

_______________________________________________
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

_______________________________________________
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: Tina TSOU <[email-masked]>
Date: Mon, 11 Sep 2006 15:11:36 +0800

See in line with [Tina1: ...].

B. R.
Tina

Tina TSOU wrote:
> Hi All,
>
> I had some doubts about draft-gurbani-sip-domain-certs as following.
>  It will be appreciated if someone would like to reply it.

Tina: Thanks for a reading of the draft.  More inline.

> 1. In section 3
>
> <Quote> One way to combat this is to arrange for the proxy to possess
> two certificates -- one corresponding to "sips:example.com" and the
> other corresponding to "sips:downtown.example.com" -- and have it
> present the right one when contacted. </Quote>
>
> But as per my understanding, the proposal in this draft doesn't
> resolve this problem thereinbefore. As there is only one SIPURI
> identity in certificate, it cannot handle the proxy which had a domain
> name and a site name. Do I miss something?

Ummm...I am not sure I follow your question.  The text you quote further 
explains why having two certificates is not desirable...

[Tina1: Let me re-phrase the question: In the proposed solution in this 
draft, there is only one
URI label in the extension, but in the text quoted, there are 2 sips URI. 
How to map 2 sips URI into only one URI label?
I am not sure if one sips URI will be matched by URI label, the other URI 
will be matched by DNS label. But this is not a consistent behavior.]

> 2. As my understanding of section 4, Does it mean that certificate
> will contain two identities, one identity for transport layer, one for
> application protocol layer?

Yes.

> Is it possible to have multiple application protocol identity? e.g,
> one is sips:example.com, another is sips:donwtown.example.com.

You could conceivably have multiple application level identities bound to 
the certificate, e.g., mailto:[email-masked], sips:[email-masked], 
pres:[email-masked] and so on.  These will be present in the certificate 
as a set of URIs.

However, if you note the draft has different labels on 
"downtown.example.com" and "example.com"; the former is preceeded by a "DNS" 
label, and the latter by a "URI" label.  So they are two different 
identities.

> How about multiple kind of application layer protocols implemented by
> one site? it will have each identity for every protocols?

Example ... I think I know what you mean, but in case my understanding is 
flawed, I do not want to go off on a tangent...

[Tina1: as in your example, one domain can have multiple applications such 
as mail, pres, sips, is it mandatory to have multiple URI labels (one for 
each application)?]

> 3. In Section 5,
>
> <Quote> If the UAC performed RFC3263 resolution on the URI to reach
> the server, the SIPS identity stored in the certificate MUST be
> matched.  Otherwise, if RFC3263 resolution on the URI failed, the UAC
> MUST match the DNS label in the certificate with the name of the
> server that it opened a TLS connection to. </Quote>

> "the SIPS ... MUST be matched", which URI will be used to match this
> SIPS identity? Is it the NextHop URI UAC used to reach the server?

If by "NextHop URI" you mean the R-URI or the topmost Route URI, yes.

[Tina1: yes, this is what I mean for "Nexthop URI".]

> If it's the NextHop URI and 3263 resolution failed, how the UAC can
> find the server and then get the certificate from the server?

Let's say you had a request destined to "sip:[email-masked]".
Doing an rfc3263-resolution on example.com domain will yield a set IP 
address, port, transport tuples.  If when contacted over TLS, the server 
presents a certificate with the SAN label "sips:example.com", then you can 
be sure that your connection reached the right destination.

Now, let's say that as a result of a Route list, you had a request destined 
to "sips:[email-masked]", where downtown is a specific host in 
the example.com domain.  NAPTR and SRV of "downtown.example.com" may not 
yield any RRs, so you would do a A/AAAA lookup.  If when contacted over TLS, 
the server presents a certificate with the SAN label 
"DNS:downtown.example.com", then you can be sure that your connection has 
reached the right destination.

[Tina1: I feel that the statement "This NATPR and SRV may not yield any RRs" 
doesn't mean 3263 resolution failed, it only means NAPTR or SRV fails, but 
A/AAAA lookup will succeed, so 3263 resolution still succeed.]

Also, for sips:downtown.example.com, it may also yield NAPTR RR, say the 
server want to map this sips URI to TLS over SCTP. As per the rule in draft, 
if the NAPTR/SRV/A query success, the URI used for query should match the 
URI label which is sips:example.com in your case, obviously it cannot match. 
Is anything missed?

Note that in the last case above, it may be the same server that was 
contacted during the first case.  But two different URIs were used to reach 
it; however, by having the right set of identities in the certificate, the 
server is accessible to either URI.

[Tina1: As in the certificate, there is already a DN label which intimates 
the domain and the domain of URL label is same as DN label, why is the URI 
label required?]

[Tina1: One more:

In section 9, para 3,
<Quote>Certainly, this means that the domain must share the domain's private 
key with the hosting service.</Quote>

Why does the hosting service have to share the same private key? Is it not 
allowed to have one private key per virtual domain?]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 14 Sep 2006 16:46:45 -0500

> See in line with [Tina1: ...].

Tina: Please see inline.

(Tina's email is in its entirety at
http://www1.ietf.org/mail-archive/web/sip/current/msg16278.html;
here I quote her questions).

> URI label in the extension, but in the text quoted, there are 2 sips 
> URI. How to map 2 sips URI into only one URI label?
> I am not sure if one sips URI will be matched by URI label, the other 
> URI will be matched by DNS label. But this is not a consistent behavior.]

I think we are talking past one another ... it is not the intent
to map two SIP URIs into one.  All the section you quote is
trying to say is that if a proxy is known through multiple
names (i.e., sips:example.com and sips:downtown.example.com), then
it is expected that it has keying material corresponding to each
identity, and that it presents the right certificate when
contacted.  The draft is trying to argue that a proxy can possess
one certificate with multiple identities to allow cases where
it can present the same certificate when contacted through a
generic URI like "sips:example.com" and a host-specific URI
(that may appear in a Route) like "sips:downtown.example.com".

> [Tina1: as in your example, one domain can have multiple applications 
> such as mail, pres, sips, is it mandatory to have multiple URI labels 
> (one for each application)?]

Yes; see example certificate in sec-flows-01, Section 4.3.

> [Tina1: I feel that the statement "This NATPR and SRV may not yield any 
> RRs" doesn't mean 3263 resolution failed, it only means NAPTR or SRV 
> fails, but A/AAAA lookup will succeed, so 3263 resolution still succeed.]

Yes, you are right.  We should qualify the phrase "RFC3263 resolution
on the URI failed"...

> server want to map this sips URI to TLS over SCTP. As per the rule in 
> draft, if the NAPTR/SRV/A query success, the URI used for query should 
> match the URI label which is sips:example.com in your case, obviously it 
> cannot match. Is anything missed?

In the above case, "sips:downtown.example.com" is a delegated
subdomain, and thus the URI label in its certificate should say
"URI:sips:downtown.example.com" and not "URI:sips:example.com".

> [Tina1: As in the certificate, there is already a DN label which 
> intimates the domain and the domain of URL label is same as DN label, 
> why is the URI label required?]

Do you mean DNS label or DN (Distinguished Name)?  I presume you
meant DNS; if so then this catches the case where you are
sending request through a specific proxy (probably due to R-R).
When you opened a TLS connection to that proxy, it will present
to you a certificate that had the hostname corresponding to the
one that you opened the TLS connection to.

> In section 9, para 3,
> <Quote>Certainly, this means that the domain must share the domain's 
> private key with the hosting service.</Quote>
> 
> Why does the hosting service have to share the same private key? Is it 
> not allowed to have one private key per virtual domain?]

In case of a virtual SIP server, the certificate (and its keying
material) is owned by me, but the server itself is running on a
third party's host.  So I do have to make the keying material
available to the operator...

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)