Re: [Sip] Using TLS in the first hop - Bug in RFC 5630

"Horvath, Ernst" <> Fri, 16 September 2011 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 953EE21F8BA8 for <>; Fri, 16 Sep 2011 03:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k8SSDeYqSvxq for <>; Fri, 16 Sep 2011 03:10:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C7CFE21F8BA0 for <>; Fri, 16 Sep 2011 03:10:47 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id 4F5191EB8404; Fri, 16 Sep 2011 12:12:58 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 16 Sep 2011 12:12:58 +0200
From: "Horvath, Ernst" <>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Date: Fri, 16 Sep 2011 12:12:57 +0200
Thread-Topic: [Sip] Using TLS in the first hop - Bug in RFC 5630
Thread-Index: AcxztBNv2wVVtuLSQfGgNpmR+QHCawAosr8g
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Sep 2011 10:10:48 -0000


> -----Original Message-----
> From: Iñaki Baz Castillo [] 
> Sent: Donnerstag, 15. September 2011 16:31
> To: Horvath, Ernst
> Cc:
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 2011/9/15 Iñaki Baz Castillo <>et>:
> >> It may work for the 1st request. But in a subsequent 
> mid-dialog request in the reverse direction the contact URI 
> becomes the Request-URI, which is now SIPS, and therefore the 
> Contact in this request must also become SIPS, and you end up 
> in an all-SIPS case.
> This is not true. The in-dialog request will have, indeed, a RURI with
> SIPS schema, but it will also contain a top Route with SIP schema, so
> it takes preference and there is no need at all to set a SIPS Contact
> URI.

Well, I read RFC 3261 differently. 8.1.2 says:

   Otherwise, the procedures are applied to the first Route header field
   value in the request (if one exists), or to the request's Request-URI
   if there is no Route header field present.  These procedures yield an
   ordered set of address, port, and transports to attempt.  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.

This behaviour overrides the transport indicated in the Route header if 
the Request-URI is SIPS. And it applies to mid-dialog requests as well.
BTW, RFC 5630 has some text on your original point:  SIPS in a Dialog

   If the Request-URI in a request that initiates a dialog is a SIP URI,
   then the UAC needs to be careful about what to use in the Contact
   header field (in case Record-Route is not used for this hop).  If the
   Contact header field was a SIPS URI, it would mean that the UAS would
   only accept mid-dialog requests that are sent over secure transport
   on each hop.  Since the Request-URI in this case is a SIP URI, it is
   quite possible that the UA sending a request to that URI might not be
   able to send requests to SIPS URIs.  If the top Route header field
   does not contain a SIPS URI, the UAC MUST use a SIP URI in the
   Contact header field, even if the request is sent over a secure
   transport (e.g., the first hop could be re-using a TLS connection to
   the proxy as would be the case with [RFC5626]).


> RFC 5630:
> 5.1.2.  UAS Behavior
>    When presented with a SIPS URI, a UAS MUST NOT change it to a SIP
>    URI.
>    As mandated by [RFC3261], Section 12.1.1:
>       If the request that initiated the dialog contained a SIPS URI in
>       the Request-URI or in the top Record-Route header field 
> value, if
>       there was any, or the Contact header field if there was 
> no Record-
>       Route header field, the Contact header field in the 
> response MUST
>       be a SIPS URI.
> In our case *there is* a Record-Route in the INVITE arriving to the
> UAS and it does contain a SIP URI, so the Contact in the response from
> the UAS does not need to be a SIPS URI.
> Anyhow I insist: SIPS and TLS usage is a pain. Nobody understands it
> (it's clear given any mail thread about this topic) and everybody does
> wrong assumptions. I think SIP authors should worry about this reality
> and react.
> Regards.
> -- 
> Iñaki Baz Castillo
> <>