IETF Logo Mail Archive

Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Wed, 29 June 2016 01:59 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 C6BFE12B049 for <insipid@ietfa.amsl.com>; Tue, 28 Jun 2016 18:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 A1ZR2jgBg3Ta for <insipid@ietfa.amsl.com>; Tue, 28 Jun 2016 18:59:20 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A972B12B031 for <insipid@ietf.org>; Tue, 28 Jun 2016 18:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3826; q=dns/txt; s=iport; t=1467165560; x=1468375160; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vDjzxornxREf6IEhRYWJYRkxfEkbhUWVWye3vOycopM=; b=NUYWjJTEfeVBP+/q34SKCBuEM3BlL+E5duSWw7qlWuxmTQ/nn4/bZTky qXuvpMXpebH0QaoGwNbVhbdExQm1aNyqQfQk5M+UbEoeryMih2pON7vep 5u+IQOCrVnIDq7p8Y6EwbIhWu0Q+9pKMiaF+ks5HS96b0pq71ASLxZEa4 M=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ABAgBDKnNX/40NJK1bgz5WfQa6NoF7FwuFLEoCgTM4FAEBAQEBAQFlJ4RMAQEBAwEBAQEgSwQHBQsCAQgYKgICJwslAQEEDgUOiBoIDrNFkC8BAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGKIF3CIJOgTmGCCuCLwWZAwGDLYFsiSGPJZAAAR42ghWBW26IP38BAQE
X-IronPort-AV: E=Sophos;i="5.26,543,1459814400"; d="asc'?scan'208";a="291313570"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2016 01:59:19 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5T1xJdS027699 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 01:59:19 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 21:59:18 -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; Tue, 28 Jun 2016 21:59:18 -0400
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: Brett Tate <brett@broadsoft.com>
Thread-Topic: [Insipid] draft-ietf-insipid-session-id versus RFC 3323
Thread-Index: AdHRa3mN5MulHSFWQ++NJW6ws0igKAAX+N8A
Date: Wed, 29 Jun 2016 01:59:18 +0000
Message-ID: <D98EFE31-60FF-4038-8D81-36572B4A39CF@cisco.com>
References: <21575ee6e889d5d4fdd306e7ca579185@mail.gmail.com>
In-Reply-To: <21575ee6e889d5d4fdd306e7ca579185@mail.gmail.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.116.123.194]
Content-Type: multipart/signed; boundary="Apple-Mail=_656DEF00-717F-44B5-A3A4-145C4D3CBE76"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/Ex-hUDhlGzWJaOdBobzzFumBmjs>
Cc: "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323
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 01:59:23 -0000

Brett,

Looking through RFC 3323, the one section you called out was the one I also noticed could potentially apply. The question then becomes whether or not the Session-ID header is both “non-essential” and “informational”. I would say it is largely informational, however whether it is essential or not depends on your definition of essential. Could it be considered “essential” for troubleshooting? Maybe not because you could troubleshoot without it - it would just be more difficult - but it is not absolutely necessary (essential). However, a customer may have some diagnostic infrastructure in place that relies on the presence of the Session-ID header in which case then it is essential for their tools to work.

Also, the Session-ID behaves similar to a Call-ID header and 3323 does not mandate that the privacy service modify the Call-ID header (it MAY) and even then, the reason it gives for modifying Call-ID is "since the Call-ID commonly contains a hostname or IP address corresponding to the originating client” which the Session-ID header does not provide as the Session Identifier itself does not reveal any information about the user or device. It can only potentially reveal a relationship between two parts of a session.

Are there any examples of other headers that implementers of 3323 have not removed based on the clause in section 5.3? Do you have a strong opinion either way? I can see arguments for and against removing it, so I don’t have a strong opinion. Either way, does it bear mentioning in the Session-ID specification?

-Paul



> On Jun 28, 2016, at 2:33 PM, Brett Tate <brett@broadsoft.com> wrote:
> 
> Hi,
> 
> Since the topic of privacy was raised... should the following snippet from
> RFC 3323 cause the Session-ID to be removed by the privacy service?  If
> not, why?  I thought I'd ask since Session-ID appears to be a
> non-essential informational header.
> 
> RFC 3323 section 5.3:
> 
> "Note that the privacy service MUST remove any non-essential
> informational headers that have been added by the user agent,
> including the Subject, Call-Info, Organization, User-Agent, Reply-To
> and In-Reply-To."
> 
> Thanks,
> Brett
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid

v2.23.0 | Report a Bug | By Email