Re: [Insipid] draft-ietf-insipid-session-id-10: comments

"Paul E. Jones" <> Sat, 14 February 2015 16:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 28F1C1A6F39 for <>; Sat, 14 Feb 2015 08:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oYQja0JNTGRP for <>; Sat, 14 Feb 2015 08:08:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B8171A6F38 for <>; Sat, 14 Feb 2015 08:08:32 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t1EG8SAd003075 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Feb 2015 11:08:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1423930110; bh=OVFt3zmeG0Uz4dAwz5kLfcqx00ux87QlN0iRxzcvDh0=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=QSzOB+zmWcDEHX/NUufcx2+jKy1QdaFwT1PcoNP+GCSSRmR96FFqWnsE78Rcr4m3K bQslhuwI/j6+rvU2hTd38+ekM190waa3CJDbBxxdSdF/y/kJ3/4CEeFsfp8L3yyGEb 5Zr2ib2QCfXHEPTL49mYdkQ8MHRt15osOreo6p0w=
From: "Paul E. Jones" <>
To: Paul Kyzivat <>,
Date: Sat, 14 Feb 2015 16:08:32 +0000
Message-Id: <em098d5c73-5c4e-436a-bd42-7b9aff663b90@helsinki>
In-Reply-To: <>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Feb 2015 16:08:37 -0000


>>>>That would be true of intermediaries like PBXes that are switching 
>>>>from one leg to another. It's only in situations where the 
>>>>is going to do something that causes endpoints to have the wrong 
>>>>that they need to ensure they convey the right value. If the SBC is 
>>>>in the business of switching call legs from one device to another 
>>>>like a
>>>>PBX does, it would not have to maintain this state at all.
>>>I think *most* B2BUAs will sometimes need to originate messages. 
>>>- send a BYE to terminate a session by policy
>>>- send a session timer refresh.
>>>Any B2BUA that will ever originate a message needs to maintain this
>>Fair point, though this is not really altering a value -- which is 
>>most of Section 7 deals with. In this case, it would be just using
>>known values to initiate messages.
>The point is that such devices must keep state remembering the values 
>to use.


>>But, I don't think we speak about that. Want to suggest a blurb to 
>>Maybe some "Finally, " text at the end (after that "Having said the
>>foregoing," paragraph I proposed to Brett) like this:
>>Finally, intermediaries compliant with this specification that 
>>messages not in response to having received a message from a remote
>>endpoint, such as sending a BYE to terminate a dialog, MUST ensure 
>>the proper Session-ID value is conveyed in that message. If the UUID 
>>the remote endpoint is known, that value MUST be used as the
>>"local-uuid" value of the transmitted message. If the UUID of the
>>remote endpoint is unknown, then the intermediary MUST use either the
>>null UUID (preferred) or fabricate a UUID to populate the "local-uuid"
>>field. Likewise, if the UUID of the receiving endpoint is known, that
>>value must be included in the "remote-uuid" field. If the UUID of the
>>receiving endpoint is unknown, the "remote-uuid" field must be set to
>>null UUID.
>I think that almost works, depending on what "is known" means.
>A box that doesn't maintain state about the last values used could be 
>considered to "not know" the values when sending a new message.
>Also, from the perspective of the intermediary, both of the endpoints 
>are "remote endpoints".
>If the intermediary is between Alice and Bob, and it has seen a message 
>containing {A,B}, then when originating a message toward Bob it should 
>include {A,B}, and when originating a message toward Alice it should 
>use {B,A}.
>But I think *saying* that in a clear way is going to require more text. 

Your request and one of Brett's is the same.  In trying to enhance the 
paragraph related to tracking UUID values, maybe we have it covered.  
So, let's remove the last paragraph I propose above and have this as the 
first two paragraphs of Section 7:

The Call-ID often reveals personal, device, domain or other sensitive 
information associated with a user, which is why intermediaries, such as 
session border controllers, sometimes alter the Call-ID.  In order to 
ensure the integrity of the end-to-end Session Identifier, it is 
constructed in a way which does not reveal such information, removing 
the need for intermediaries to alter it.
Intermediaries MAY track the Session Identifier values associated with a 
transaction and dialog.  However, since it is generally NOT REQUIRED and 
because of other reasons, they might provide inaccurate Session-ID 
values when generating related requests and responses.  As a general 
rule, intermediaries MUST NOT alter the UUID values found in the 
Session-ID header, except as described in this section.  When 
autonomously originating a message, an intermediary MAY insert a tracked 
UUID value, or the “null” UUID or a locally generated UUID (in the case 
that there is no known UUID for the peer UA), or not include the 
Session-ID header at all to avoid miscommunicating an incorrect UUID 
How does that sound?