Hi,
Let me try explaining the scenario in
simple terms. Consider the following setup
where P is the proxy responsible for Bob's
domain (biloxi.com).
Alice --> P --> Bob
Alice starts the dialog as:
SUBSCRIBE sips:[EMAIL PROTECTED] SIP/2.0
Contact: <sips:[EMAIL PROTECTED]>
...
However, P decides to switch from TLS to TCP when
forwarding the call to Bob (it is allowed to do
so as SIPS only guarantees TLS to be used till
the domain of the callee; there are also sections
that talk about a proxy being on a security perimeter...
so a switch from TLS to TCP is legal). Since it
switches from TLS to TCP, it inserts a Record-Route
and the message that reaches Bob will look like:
SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0
Record-Route: <sip:ProxyIP:5060;transport=tcp;lr>
Contact: <sips:[EMAIL PROTECTED]>
...
Ofcourse, in the response path, the proxy P
modifies its Record-Route to become a SIPS URI
so that the hop from Alice to P remains on TLS
and the hop from P to Bob remains on TCP.
Now, when Bob sends a NOTIFY to Alice, the message
would be formed as :
NOTIFY sips:[EMAIL PROTECTED] SIP/2.0
Contact: <sip:[EMAIL PROTECTED]>
Route: <sip:ProxyIP:5060;transport=tcp;lr>
...
Though one would expect the NOTIFY to be sent to
ProxyIP:5060 on TCP, the following rule of RFC 3261
suggests otherwise:
Section 8.1.2 (UAC sending a request):
"Independent of which URI is used as input to the
procedures of [4], if the Request-URI specifies a
SIPS resource, the UAC MUST follow the procedures
of [4] as if the input URI were a SIPS URI."
Going by the above rule, though the ordered IP:port:transport
is ProxyIP:5060:tcp, the request is still expected
to be sent on TLS !! So now, Bob will send the request
to ProxyIP:5060 on TLS and proxy P will probably fail
to parse the message as this is its TCP interface.
This problem has been raised by Christer Holmberg
about a year back. Till a bis revision of the RFC comes
out, what are implementations expected to do in the
above case ??
Thanks for your time. Christer, if you are aware of what
was the (maybe offline) consensus, please comment.
Thanks & Regards
-Biju
---------------------- Forwarded by K Biju/BLR/HSS on 07/09/2004 01:43 PM
---------------------------
(Embedded image moved to file: pic60951.jpg)
K Biju
(Embedded image moved to file: pic16579.jpg)
07/07/2004 07:39 PM
(Embedded image moved to file: pic55181.jpg)
To: Jonathan Rosenberg <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Sip] SIPs Question (Document link: K Biju)
Hi ,
See inline >>>> for my response
Thanks & Regards
-Biju K
Jonathan Rosenberg <[EMAIL PROTECTED]> on 07/06/2004 11:24:59 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: [Sip] SIPs Question
inline.
[EMAIL PROTECTED] wrote:
>
>
>
> Hi all,
> I have come across a typical scenario when using TLS.
>
> A UAC sends a request (SUBSCRIBE) over TLS and the Proxy Server (P1) on
> the
> domain of the UAS converts this request from TLS to non-TLS and also
> record-routes
> this dialog.
> The Proxy server hence inserts the SIP URI scheme in the Record-Route
> header,
> when sending this request to the UAS.
>
> Now for subsequent messages (NOTIFY) from UAS to a UAC, UAS sends it on
> TLS.
It shouldn't. The next hop, as far as its concerned, is a URI that is
not using TLS transport, unless the DNS SRV procedures when resolving
the record-routed URI would indicate TLS.
>>>>> In my mentioned case the Request-URI sent by the UAC has a SIPS
>>>>> URI. So as per the RFC section 8.1.2 "Independent of which URI is
used
>>>>> as input to the procedures of [4], if the Request-URI specifies a
SIPS
>>>>> resource, the UAC MUST follow the procedures of [4] as if the input
URI
>>>>> were a SIPS URI."
>>>>> Hence subsequent messages (NOTIFY) are getting sent on TLS using a
>>>>> non-TLS port, set in the Route Header.
> But since the Proxy has record-routed the request, UAS sends the
responses
> to the
> address mentioned in the Route header.
> This being a non-TLS transport, the UAS ends up sending the TLS response
on
> a
> non-TLS port.
> This behavior is still in accordance with RFC 3261- section12.1.1.
Right. This is the correct behavior.
>
> I have seen a similar issue raised in this mailing list sometime before
but
> no concrete solution was
> available.
> http://www1.ietf.org/mail-archive/web/sip/current/msg06712.html
>
> How is this planned to be handled ??
I'm not sure I see the problem. If you want tls all the way, the UAC
should have sent the request with a sips URI.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Technology Officer Parsippany, NJ 07054-2711
dynamicsoft
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
