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

"Paul E. Jones" <paulej@packetizer.com> Fri, 12 September 2014 21:09 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 42A641A00F0 for <insipid@ietfa.amsl.com>; Fri, 12 Sep 2014 14:09:12 -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 rwO3rmvtO8Ps for <insipid@ietfa.amsl.com>; Fri, 12 Sep 2014 14:09:06 -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 3FAF41A009A for <insipid@ietf.org>; Fri, 12 Sep 2014 14:09:06 -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 s8CL8vxe030524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Sep 2014 17:08:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1410556139; bh=kyhjaJjIMpUV6jhYPx2xethrAJYifq4Q0SHYywANfqE=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=QK3QBhrB5Qr/xfv1MitfihVPV11lQTS/p14qjgyEpSVS89BiiVBKm0MtGe8IvUy7P JENag10C3iHN+dIzHcEzm15A117InOsvsaxxn+ukJAO8C4hANaCNrmAt5i8brWi0fB Xnty3ic20asyZWAf30//T0HM49BwWKayPvVIzCCY=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Adam Gensler (agensler)" <agensler@cisco.com>
Date: Fri, 12 Sep 2014 21:09:09 +0000
Message-Id: <em7de453b8-e55f-4799-9bdd-63adb655d675@sydney>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4498FF@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/ePAnKYR7pMjQlq0CiQ3nEZWYzDU
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: Fri, 12 Sep 2014 21:09:12 -0000

Christer,

------ Original Message ------
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Paul E. Jones" <paulej@packetizer.com>; "Adam Gensler (agensler)" 
<agensler@cisco.com>
Cc: "insipid@ietf.org" <insipid@ietf.org>
Sent: 9/12/2014 5:01:04 PM
Subject: RE: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

>Hi,
>
>>>>>You need to give people technical reasons why they reasons they
>>>>>modify Call-ID don't apply to Session-ID. "Because the draft says 
>>>>>so"
>>>>>is not such reason :)
>>>>
>>>>How about we modify the first paragraph of Section 7 to read this 
>>>>way:
>>>>
>>>>"In order to ensure the integrity of the end-to-end session
>>>>identifier, intermediaries, such as proxies >or session border
>>>>controllers, MUST NOT alter the UUID values found in the Session-ID
>>>>header, >except as described in this section."
>>>>
>>>>Would that help or do you think we need something else?
>>>
>>>Unfortunately I don't think it will help.
>>>
>>>No matter what the spec says, intermediaries will modify the header
>>>field if they see a need to do so. You need to describe why such need
>>>does not occur for the Session-ID header field.
>>>
>>
>>  The reasons the Call-ID or other headers were changed at the SBC was 
>>because they revealed
>>  specific information about the user, including device information, 
>>user identifiers, etc. The Session > Identifier is defined to be 
>>random (per section 4.1 of the solution spec). This is also spelled 
>>out in
>>  the referenced requirements document.
>
>Nobody is going to read the requirements document - you need to 
>describe it in THIS document.

Oh, I wasted time on a document nobody will read?!?! :-)


>
>>Given that, what more do we really need to say here? I'm happy to 
>>modify that sentence in some >way that helps, but I don't want to make 
>>it so complex that it gets in the way of the procedures. >Maybe we 
>>need something in the security considerations section?
>>
>>  I think I understand roughly what you're shooting for, but I'm not 
>>sure what we can add that
>>  doesn't confuse the text, replicate text from the requirements 
>>document, etc. Can you suggest
>>  some text and where to put it?
>
>I think the text above, about revealing sensitive information, is good 
>:)
>
>

How about this?

"In consideration of the fact that the Session Identifier is constructed 
in such a way as to not reveal any personal, device, or domain 
identifying information and in order to ensure the integrity of the 
end-to-end session identifier, intermediaries, such as proxies or 
session border controllers, MUST NOT alter the UUID values found in the 
Session-ID header, except as described in this section."

Paul