[asterisk-dev] [svn-commits] mmichelson: branch 12 r399083 - in /branches/12: include/asterisk/ res/

[Matthew Jordan]

On Mon, Sep 16, 2013 at 6:31 AM, Olle E. Johansson <oej at edvina.net> wrote:

>
> 16 sep 2013 kl. 11:40 skrev Saúl Ibarra Corretgé <saghul at gmail.com>:
>
> >
> > [snip]
> >
> >> After reading your e-mail and the RFCs, I don't have a clear
> >> understanding either of all of the issues surrounding usage of a SIPS
> >> URI instead of a SIP URI with TLS as transport. The fact that SIPS does
> >> not equate to "best-effort" TLS obviously has implications if hops in
> >> the middle don't support TLS (you either think you're secure but aren't,
> >> or your calls fail, or... something else perhaps?). What I don't have a
> >> clear understanding of is why we should prefer SIP with TLS as the
> >> transport over SIPS. Couldn't a user make the argument that they really
> >> don't want "best-effort" - that is, if they asked for secure
> >> communication, they want secure communication along the entire path?
> >> What explicit pitfalls are we running into by using SIPS in the URI in
> >> the contact header?
> >
> > FWIW, I'll just throw here what we do in Blink. I know it's not kosher
> as per the standard, but oh well, world is not perfect: we ignore SIPS. We
> basically treat it as it were "sip:". And we use transport=tls.
> >
> > I know Olle will want to slap me in the wrist, but that's what has
> worked so far out there in the wild. Sue me! ;-)
>
> I'll take care of the slapping when we're on tour. :-)
>
> We are several who have voted for deprecating SIPS: totally. The meaning
> is very unclear and the
> benefits of using it even more so.
>
> The important fact is that in this case we don't know if the other UA used
> udp, tcp or TLS - just the
> fact that we get a request over a TLS connection doesn't mean that we can
> upgrade to SIPS:.
> Could be a proxy or a b2bua that upgraded to TLS based on NAPTR or policy.
> Adding sips: in a
> contact without getting an inbound complete SIPS: request (with all the
> right headers in place) will break
> communication.
>

Based on your above comment - and since this particular commit is concerned
with generating Contact headers when creating a server side SIP dialog when
using TLS - I think we can break down our questions into three categories:

1. The Contact header URI scheme. Should we mirror Blink's behavior and
just use SIP URIs for all Contact headers? Should we, under certain
circumstances, generate a SIPS URI in our Contact header? Under what
circumstances should we feel it safe to do so?

2. The Contact header transport parameter. Should we ever put
";transport=tls" in our Contact header? When we wish to be contacted over
TLS, should we put any sort of transport parameter in our Contact header?
If not, how do we indicate that we wish to be contacted over TLS?

3. The potential effects that 1. and 2. have on the rest of the SIP traffic
Asterisk generates for this dialog. What other areas do you have in mind
that might be affected? Some headers are likely taken care of for us by the
SIP stack, (Route, Via, etc.)  but there may be others that we are not
thinking of.

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130916/5b639bc5/attachment.htm>