IETF Logo Mail Archive

Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Wed, 29 June 2016 20:10 UTC

Return-Path: <pgiralt@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA79012D681 for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 13:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 iPhp6XzNUL7B for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 13:10:06 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05A512B03D for <insipid@ietf.org>; Wed, 29 Jun 2016 13:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7337; q=dns/txt; s=iport; t=1467231006; x=1468440606; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=atFBJT5OJOC3TUqLPkDyxAsL4ah8SffU3PpOalCLCu0=; b=gsq1LssgMxOeBaRK1OZUyfiwqajLdBOhrMjCi48lqe/cJ5j/ACC4M9UC W5pkyMyEDny/QEL4vkbGpU1n4KIIWhvNcMPWLDuX9DfIretmd4BRFPeHS 4AP8CusPJJ7IB34VdVhisHfngcAJ8qwVdV3RV2q9VsUOxwTVM/PgssG+h o=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArAgA8KnRX/4sNJK1bgnBOgVm0Q4UBgXuGGAKBMjgUAQEBAQEBAWUnhE0BAQMBI1YQAgEIQgICMiUCBA4TiBoIs3iQFgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OhiiBdwiCToQqgxcrgi8FhgSTAQGDLYFshliCTIFphFSIaJACAR42gggcgUyJN38BAQE
X-IronPort-AV: E=Sophos;i="5.26,548,1459814400"; d="asc'?scan'208,217";a="123277539"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2016 20:10:05 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5TKA5GO027038 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 20:10:05 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 16:10:04 -0400
Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 16:10:04 -0400
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt
Thread-Index: AQHRzdIv8M2blTO35k+l2Gt9c0ch+5/5BxMAgAUeHYCAAXNIgIABj38AgAAD4AA=
Date: Wed, 29 Jun 2016 20:10:04 +0000
Message-ID: <49633303-629D-4CE3-A691-72D4E886080F@cisco.com>
References: <20160624043751.12660.23306.idtracker@ietfa.amsl.com> <99E92338-11D2-404C-BEC7-EDEB9B0C2792@cisco.com> <48BA34F8-5D0A-4597-A3FA-D9E8392F4323@nostrum.com> <22D19CAA-9CF5-4666-8839-20568FE3B35B@cisco.com> <77585AF0-736F-4BE7-B7D8-E1979A962B58@nostrum.com>
In-Reply-To: <77585AF0-736F-4BE7-B7D8-E1979A962B58@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.81.96.60]
Content-Type: multipart/signed; boundary="Apple-Mail=_E2CBADF0-3C4A-4C2C-A842-1A5224ACB16E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/KGBRAhOP3yHn7yB_Qp0iNKEkUxQ>
Cc: "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 29 Jun 2016 20:10:09 -0000

> 
> That text talks about when the UUID MUST NOT change. I'm looking for text that says a UUID value MUST NOT be reused across multiple "sessions" (as sessions are defined in this draft.) The point is to avoid an accidentally persistent identifier that could be used to track user/UA activity across multiple sessions.

I see where you are coming from now. I hadn’t payed attention to the fact that the text in 4.2 is not normative. Currently the section reads:

	The SIP User Agent (UA) initiating a new session by transmitting a SIP
         request ("Alice"), i.e., a User Agent Client (UAC), will create a new,
         previously unused, UUID and transmit that to the ultimate destination UA
         ("Bob").  Likewise, the destination UA ("Bob"), i.e., a User Agent Server (UAS),
         will create a UUID and transmit that to the first UA ("Alice").

If I just change the “will” to MUST and expand on the UAS also having to create a previously-unused UUID like below, does this address the concern?

	The SIP User Agent (UA) initiating a new session by transmitting a SIP
         request ("Alice"), i.e., a User Agent Client (UAC), MUST create a new,
         previously unused, UUID and transmit that to the ultimate destination UA
         ("Bob").  Likewise, the destination UA ("Bob"), i.e., a User Agent Server (UAS),
         MUST create a new, previously unused, UUID and transmit that to the
	first UA ("Alice").

Alternatively, I could add some normative text in Section 6 for endpoint behavior, but I think just modifying the above should address the concern. Please let me know your thoughts.

-Paul

v2.23.0 | Report a Bug | By Email