Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

"Paul E. Jones" <paulej@packetizer.com> Sun, 14 September 2014 20:52 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681B1A02BA for <insipid@ietfa.amsl.com>; Sun, 14 Sep 2014 13:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.644
X-Spam-Level:
X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15wB9tGygFou for <insipid@ietfa.amsl.com>; Sun, 14 Sep 2014 13:52:44 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1DF1A0027 for <insipid@ietf.org>; Sun, 14 Sep 2014 13:52:44 -0700 (PDT)
Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s8EKqOdH013372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Sep 2014 16:52:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1410727945; bh=CcAeJfpVgc8p7qwSAuqSCPW0PdpAIYjfYsYBW91v0Eo=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=Mx9n40bezPgPMBMN0vItVn5PdABxmcDMQWl0s2rGjfA8o59/9DGxSTb7BLz6kBt7k D3GfMjjKWh3WChou1QnOE7Q6jHhfkJL5YA9dwWwgjxb82IJ1wJtonyj/SFxZvSFe+x 4B5OIvC4kBVz6kiJOx6OXiTuTuWaR0m9oUfxOLeU=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Adam Gensler (agensler)" <agensler@cisco.com>
Date: Sun, 14 Sep 2014 20:52:29 +0000
Message-Id: <em4dc6ecde-c41e-4de3-ac46-272aa003bc52@sydney>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D44A063@ESESSMB209.ericsson.se>
User-Agent: eM_Client/6.0.20617.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/09LIWxVT904MwxslX7DXUcTiRNc
Cc: "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Sep 2014 20:52:46 -0000

Christer,


>I would use different wording. Something like:
>
>"The call-id often reveal personal, device, domain or other sensitive 
>information associated
>with an end-user, which is why intermediaries, such as proxies and 
>session border
>controllers 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 (except as described 
>in this section)."

This is OK, though it removes the "MUST NOT" in the paragraph that I 
think is important.  How about this slight variation?

"The Call-ID often reveal personal, device, domain or other sensitive 
information associated with a user, which is why intermediaries, such as 
proxies and 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.  As such, intermediaries MUST 
NOT alter the UUID values found in the Session-ID header, except as 
described in this section."

Paul